[Starlingx-discuss] Contrib or Experimental tools location ??

[Badea, Daniel]

That's not what https://wiki.openstack.org/wiki/StarlingX/CodeSubmissionGuidelines says:
...
Add the core reviewers for the affected sub-project to the review as well as any other interested reviewers
    The core reviewers are listed on each sub-project wiki pages. The list of sub-projects is available here
...
________________________________________
From: Penney, Don
Sent: Wednesday, April 17, 2019 23:14
To: Badea, Daniel; Dean Troyer; Curtis
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: RE: [Starlingx-discuss] Contrib or Experimental tools location ??

Core reviewers should be watching the repos on which they're a core. If there's a specific person required for an update as an SME, add them. But otherwise, I wouldn't think it should be necessary to explicitly add the cores to a review.


-----Original Message-----
From: Badea, Daniel [mailto:Daniel.Badea at windriver.com]
Sent: Wednesday, April 17, 2019 4:11 PM
To: Dean Troyer; Curtis
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??

I have a script that can be used to automatically add code reviewers for a commit (instead of opening the list of core reviewers in one browser tab and manually add them one by one in the review page). Should this be a GitHub gist, a small repo under my GitHub account or a subfolder in starlingx-staging/unofficial-tools-where-code-goes-to-die?

Thanks,
Daniel
________________________________________
From: Dean Troyer [dtroyer at gmail.com]
Sent: Friday, March 15, 2019 15:55
To: Curtis
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??

On Fri, Mar 15, 2019 at 8:39 AM Curtis <serverascode at gmail.com> wrote:
> Ultimately I believe we are arguing different goals with the same points.
>
> I'm ok with bit rot, it's inevitable, and can actually be a good thing. I'm ok with code with lower standards being contributed to a place where it can be legitimized.
>
> These things are pros to me. :)

I am not against having a place for unofficial code to go and rot, I
am against it being associated with the StarlingX name in a way that
drags down the perception of the code we produce.  And that is all we
produce in the end, code in repositories.

> There would have to be some standards, eg. no pyc files, no -2s to new contributors, etc. Arbitrary no, curated yes.

To me 'curated' includes vetting suitability for purpose.  Untested
code is broken code.

I would support a repo in github.com/starlingx-staging or an index
anywhere but not a repo in Gerrit without meeting a certain minimum of
quality and accountability.

dt

--

Dean Troyer
dtroyer at gmail.com

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss