[Starlingx-discuss] Contrib or Experimental tools location ??
Folks,
I know this was brought up as part of the Virtualbox Python deployment tool, which in that case we decided to keep it as was proposed in stx-tools/depolyment/virtualbox (logical location).
We are likely going have more contributions that fall into experimental that the community may want to try.
Should we have a contrib or experimental repo or subdirectory in stx-tools for these contributions?
For example the "StarlingX in a box" work, or another different deployment tool for qemu?
Thoughts?
Sau!
On Wed, Mar 13, 2019 at 11:00 PM Saul Wold sgw@linux.intel.com wrote:
Folks,
I know this was brought up as part of the Virtualbox Python deployment tool, which in that case we decided to keep it as was proposed in stx-tools/depolyment/virtualbox (logical location).
We are likely going have more contributions that fall into experimental that the community may want to try.
Should we have a contrib or experimental repo or subdirectory in stx-tools for these contributions?
For example the "StarlingX in a box" work, or another different deployment tool for qemu?
Thoughts?
I am in favour of having an experimental repository where useful code that is not as heavily scrutinized is stored. That code, if used over time, can be moved out of the repository into a more permanent location with full project workflows and processes applied. My canonical example is the osops-tools-contrib [0] repo. I am just always a fan of large open source projects having something like this where new perhaps inexperienced contributors can submit code, or organizations can submit code that is not "fully baked" for overall review for potential usefulness.
Now, how many contributions we might see, and what it might look like are certainly up for debate, but I still think it's a useful repository to have, and if it is not used over time then we can remove it. But without it we'll never know. :)
I am also thinking of myself here as the stx community is putting on a workshop at the summit and there will likely be code and docs that go with that, and perhaps this would be a good place for that kind of thing to live.
Thanks, Curtis
[0]: https://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/README.rst
Sau!
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Wed, Mar 13, 2019 at 9:59 PM Saul Wold sgw@linux.intel.com wrote:
We are likely going have more contributions that fall into experimental that the community may want to try.
Should we have a contrib or experimental repo or subdirectory in stx-tools for these contributions?
My experience with this sort of thing is over time they bit-rot and are slowly, if at all, updated, much like many wikis. There is also a perception of blessing by the project when hosted in project-controlled places, be it a git repo or a subdirectory within another project.[0]
The bar for anyone to host their own workspaces publicly is fantastically low these days, with Github, Gitlab, BitBucket and friends all available for free. I see that discovery is one of the issues here, we could host a directory of these repos centrally (wiki page?). What is the benefit of placing arbitrary code into a StarlingX repo over a personal Github account + having a directory listing these personal repos? I see a benefit in the legitimization that putting it under an stx repo gives (this one of my concerns), what are the other benefits?
I would feel much better about doing this in an stx repo if the core group (there will be a limited group of people with merge permissions here, yes?) has the responsibility to curate the content of a contrib repo.
dt
[0] We have already seen this ourselves around some of the scripts in stx-tools/deployment that were put there for a specific purpose and users discovered them and expected them to be supported.
On Thu, Mar 14, 2019 at 5:17 PM Dean Troyer dtroyer@gmail.com wrote:
On Wed, Mar 13, 2019 at 9:59 PM Saul Wold sgw@linux.intel.com wrote:
We are likely going have more contributions that fall into experimental that the community may want to try.
Should we have a contrib or experimental repo or subdirectory in stx-tools for these contributions?
My experience with this sort of thing is over time they bit-rot and are slowly, if at all, updated, much like many wikis. There is also a perception of blessing by the project when hosted in project-controlled places, be it a git repo or a subdirectory within another project.[0]
The bar for anyone to host their own workspaces publicly is fantastically low these days, with Github, Gitlab, BitBucket and friends all available for free. I see that discovery is one of the issues here, we could host a directory of these repos centrally (wiki page?). What is the benefit of placing arbitrary code into a StarlingX repo over a personal Github account + having a directory listing these personal repos? I see a benefit in the legitimization that putting it under an stx repo gives (this one of my concerns), what are the other benefits?
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 would feel much better about doing this in an stx repo if the core group (there will be a limited group of people with merge permissions here, yes?) has the responsibility to curate the content of a contrib repo.
There would have to be some standards, eg. no pyc files, no -2s to new contributors, etc. Arbitrary no, curated yes.
Thanks, Curtis
dt
[0] We have already seen this ourselves around some of the scripts in stx-tools/deployment that were put there for a specific purpose and users discovered them and expected them to be supported.
--
Dean Troyer dtroyer@gmail.com
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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
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@gmail.com] Sent: Friday, March 15, 2019 15:55 To: Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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@windriver.com] Sent: Wednesday, April 17, 2019 4:11 PM To: Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@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@gmail.com] Sent: Friday, March 15, 2019 15:55 To: Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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@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@windriver.com] Sent: Wednesday, April 17, 2019 4:11 PM To: Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@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@gmail.com] Sent: Friday, March 15, 2019 15:55 To: Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Ok, let's say explicitly setting core reviewers is not required. I have another example: if a pod or job fails while applying stx-openstack it is possible its logs are lost before I get a chance to view them. So I wrote another tool to preserve all kubernetes logs without touching current configuration (the proper way to save logs is to use a logging service).
Where should I share this tool/script? (others might find it useful for now)
-Daniel ________________________________________ From: Badea, Daniel [Daniel.Badea@windriver.com] Sent: Wednesday, April 17, 2019 23:31 To: Penney, Don; Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
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@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@windriver.com] Sent: Wednesday, April 17, 2019 4:11 PM To: Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@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@gmail.com] Sent: Friday, March 15, 2019 15:55 To: Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
I think this tool is useful, and there has been a similar tool "collect", under " ./cgcs-root/stx/stx-integ/tools/collector/scripts/collect" Maybe "./cgcs-root/stx/stx-integ/tools/" is a place to go.
On 18/04/2019, 5:10 AM, "Badea, Daniel" Daniel.Badea@windriver.com wrote:
Ok, let's say explicitly setting core reviewers is not required. I have another example: if a pod or job fails while applying stx-openstack it is possible its logs are lost before I get a chance to view them. So I wrote another tool to preserve all kubernetes logs without touching current configuration (the proper way to save logs is to use a logging service).
Where should I share this tool/script? (others might find it useful for now)
-Daniel ________________________________________ From: Badea, Daniel [Daniel.Badea@windriver.com] Sent: Wednesday, April 17, 2019 23:31 To: Penney, Don; Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
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@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@windriver.com] Sent: Wednesday, April 17, 2019 4:11 PM To: Dean Troyer; Curtis Cc: Saul Wold; starlingx-discuss@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@gmail.com] Sent: Friday, March 15, 2019 15:55 To: Curtis Cc: Saul Wold; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Contrib or Experimental tools location ??
On Fri, Mar 15, 2019 at 8:39 AM Curtis serverascode@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (6)
-
Badea, Daniel
-
Curtis
-
Dean Troyer
-
Hu, Yong
-
Penney, Don
-
Saul Wold