[Starlingx-discuss] Proposal: Basic development guidelines / rules
I would like to propose the following basic development process for StarlingX. Instead of writing a long document, I will just propose a set of guidelines. Comments and feedback will be graciously accepted. Rule 1: We will follow all the usual open source and OpenStack conventions Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. Rule 3: Code submissions should be reviewable (e.g. not thousands of lines). Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement. Rule 5: All code submissions shall have a Storyboard Story or Task associated with them and linked to in the commit message. Use the stx-* project that makes sense, or stx-upstream for upstream changes Rule 6: Code submissions for bug fixes can be posted to gerrit when ready Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code. brucej
Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code.
What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance!
I am not quite sure if I understand below: Code submissions for bug fixes do not need to be reviewed before pushing to gerrit. Bug reports should be posted to Storyboard. Are you saying that patches for bug fixing do not required code-review + 1, +2 before it merged? Or you just are saying no [RFC] requests in mailing list shall be reviewed before bug-fixing patch got submitted? Thx. - cindy -----Original Message----- From: Arce Moreno, Abraham [mailto:abraham.arce.moreno@intel.com] Sent: Thursday, June 21, 2018 11:14 AM To: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules
Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code.
What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Cindy, thanks. What I was trying to say is that since bugs should already be posted to Storyboard by the person who found them, they don't need any additional specs or discussion. Which isn't always the case, of course, since sometimes fixing a bug can require a big change. I've updated https://wiki.openstack.org/wiki/StarlingX/Contribution_Guidelines with the feedback from this thread. brucej -----Original Message----- From: Xie, Cindy Sent: Wednesday, June 20, 2018 11:19 PM To: Arce Moreno, Abraham <abraham.arce.moreno@intel.com>; Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Proposal: Basic development guidelines / rules I am not quite sure if I understand below: Code submissions for bug fixes do not need to be reviewed before pushing to gerrit. Bug reports should be posted to Storyboard. Are you saying that patches for bug fixing do not required code-review + 1, +2 before it merged? Or you just are saying no [RFC] requests in mailing list shall be reviewed before bug-fixing patch got submitted? Thx. - cindy -----Original Message----- From: Arce Moreno, Abraham [mailto:abraham.arce.moreno@intel.com] Sent: Thursday, June 21, 2018 11:14 AM To: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules
Rule 7: Code submissions for larger development tasks shall be discussed on the mailing list _prior_ to code submission, to allow for community review and feedback. Post early and often. Please review (and test!) each other's code.
What is the usual way in OpenStack to review a proposal of a change? I have 2 files, one script that downloads from a text file a list tar compressed files, is it ok to post the patch as [RFC] in this mailing list? Etherpad? Any other? Thanks for your guidance! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Wed, Jun 20, 2018 at 10:14 PM, Arce Moreno, Abraham <abraham.arce.moreno@intel.com> wrote:
What is the usual way in OpenStack to review a proposal of a change?
You push it to Gerrit. Often times people will put [WIP] at the beginning of the commit message to indicate it is not ready to be merged but you want comments or want to run the test jobs against it. There is also the "Workflow -1" (aka -W) that you can put on your own review that has the same effect. And comments are always helpful to clarify intent. Except for the -W part we can do exactly the same thing in the github repos. dt -- Dean Troyer dtroyer@gmail.com
Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done? brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Thursday, June 21, 2018 8:21 AM To: Arce Moreno, Abraham <abraham.arce.moreno@intel.com> Cc: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules On Wed, Jun 20, 2018 at 10:14 PM, Arce Moreno, Abraham <abraham.arce.moreno@intel.com> wrote:
What is the usual way in OpenStack to review a proposal of a change?
You push it to Gerrit. Often times people will put [WIP] at the beginning of the commit message to indicate it is not ready to be merged but you want comments or want to run the test jobs against it. There is also the "Workflow -1" (aka -W) that you can put on your own review that has the same effect. And comments are always helpful to clarify intent. Except for the -W part we can do exactly the same thing in the github repos. dt -- Dean Troyer dtroyer@gmail.com
On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done?
We need to do something to review design and implementation. 'blueprint' is a launchpad term that is now overloaded in akraino so let's not use it. Some Openstack projects added a spec process, including a specs repo, to iterate on the design and implementation and worked that in Gerrit. That is not the best forum for some kinds of discussions so those often got held in Irc or the -dev mailing list. And some projects used both specs and blueprints. This is one area that I think we need to suss out what we actually want and not just fall back because there is no clear single precedent to borrow. At this point a single collection of documents and review process seems sufficient, we could manage them via Storyboard or follow the specs repo format. I don't have a strong opinion there. dt -- Dean Troyer dtroyer@gmail.com
On 06/21/2018 11:27 AM, Dean Troyer wrote:
On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done?
We need to do something to review design and implementation. 'blueprint' is a launchpad term that is now overloaded in akraino so let's not use it.
Some Openstack projects added a spec process, including a specs repo, to iterate on the design and implementation and worked that in Gerrit. That is not the best forum for some kinds of discussions so those often got held in Irc or the -dev mailing list. And some projects used both specs and blueprints.
This is one area that I think we need to suss out what we actually want and not just fall back because there is no clear single precedent to borrow. At this point a single collection of documents and review process seems sufficient, we could manage them via Storyboard or follow the specs repo format. I don't have a strong opinion there.
As I see it, the main benefit of an OpenStack spec is that it goes through Gerrit and thus lets people review and comment on the iterations of the design. It also lets you go back years later and maybe figure out why things were done the way they were. I think that it's valuable to allow people to comment on in-progress designs, so as long as there's some way to do that I don't care about the exact mechanism. Chris
Hi, To chime in a little, I would suggest to keep the processes as simple as possible to start with. StoryBoard gives opportunities to add a description and also comments to a story so it can be a good forum to start with. You can always define a template to follow and/or use Gerrit for new specs later. Starting with simpler processes will help new comers to join your community easier which is extremely important in this phase. You can evolve the processes as the community grows and you identify bottlenecks or some missing steps. Thanks and Best Regards, Ildikó Váncsa Ecosystem Technical Lead, OpenStack Foundation (IRC: ildikov)
On 2018. Jun 21., at 19:58, Chris Friesen <chris.friesen@windriver.com> wrote:
On 06/21/2018 11:27 AM, Dean Troyer wrote:
On Thu, Jun 21, 2018 at 10:26 AM, Jones, Bruce E <bruce.e.jones@intel.com> wrote:
Dean - for larger changes, do you recommend we adopt a spec writing (Blueprint) process? If so, how would that be done?
We need to do something to review design and implementation. 'blueprint' is a launchpad term that is now overloaded in akraino so let's not use it.
Some Openstack projects added a spec process, including a specs repo, to iterate on the design and implementation and worked that in Gerrit. That is not the best forum for some kinds of discussions so those often got held in Irc or the -dev mailing list. And some projects used both specs and blueprints.
This is one area that I think we need to suss out what we actually want and not just fall back because there is no clear single precedent to borrow. At this point a single collection of documents and review process seems sufficient, we could manage them via Storyboard or follow the specs repo format. I don't have a strong opinion there.
As I see it, the main benefit of an OpenStack spec is that it goes through Gerrit and thus lets people review and comment on the iterations of the design. It also lets you go back years later and maybe figure out why things were done the way they were.
I think that it's valuable to allow people to comment on in-progress designs, so as long as there's some way to do that I don't care about the exact mechanism.
Chris
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
What is the usual way in OpenStack to review a proposal of a change?
You push it to Gerrit. Often times people will put [WIP] at the beginning of the commit message to indicate it is not ready to be merged but you want comments or want to run the test jobs against it. There is also the "Workflow -1" (aka -W) that you can put on your own review that has the same effect. And comments are always helpful to clarify intent.
Except for the -W part we can do exactly the same thing in the github repos.
Understood Dean! Thanks!
participants (6)
-
Arce Moreno, Abraham
-
Chris Friesen
-
Dean Troyer
-
Ildiko Vancsa
-
Jones, Bruce E
-
Xie, Cindy