Re: [Starlingx-discuss] Proposal: Basic development guidelines / rules
Hi Bruce; I think this is a good start. I have a few comments and suggestions. Eventually, we should add this to the StarlingX wiki. The title is guidelines, but, you call out rules. We should change the line items to guidelines or guidelines/rules. Also, the guidelines/rules come across without context - what is the "why" for us to want to implement/follow these guidelines. We should add the following introductory paragraph or some variant: The following guidelines are offered to help us maintain an active, collaborative, innovative and inclusive project. The guidelines are here to help us maintain focus and we understand in some case there will be exceptions, but, lets discuss the exceptions openly and while understanding the benefits and consequences. On 2018-06-15, 3:32 PM, "Jones, Bruce E" <bruce.e.jones@intel.com> wrote: 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 IJ >> I would recommend we add some references. Did you have some in mind? Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions. IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line. 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. IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message? 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 IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard. 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. IJ >> this is a good practice and will help us work efficiently. brucej _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Tue, Jun 19, 2018 at 1:33 PM, Jolliffe, Ian <Ian.Jolliffe@windriver.com> wrote:
On 2018-06-15, 3:32 PM, "Jones, Bruce E" <bruce.e.jones@intel.com> wrote: Rule 1: We will follow all the usual open source and OpenStack conventions
IJ >> I would recommend we add some references. Did you have some in mind?
I've been saying we would fall back to OpenStack as a default in the absence of anything overriding. As we build our doc set adding references for things that both override or confirm those defaults would be useful.
Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions.
IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line.
I think this is a distinct idea. A short review that does two things should be split. In the case of the upstream repos I will probably be noisy about this because of having to upstream things individually anyway.
Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement.
IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message?
"git commit -s" is sufficient. This requirement comes from the OpenStack project's intent to drop the CLA requirement in favor of DCO, and it seems like a simple thing to do from the start even if we don't have the same legal restrictions (I don't know if we do or not). LF was going to require it and enforce in Gerrit, we have that option if we want to use it.
Rule 6: Code submissions for bug fixes can be posted to gerrit when ready
IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard.
We are using only Storyboard where there is no intrinsic distinction between bugs and features.
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.
IJ >> this is a good practice and will help us work efficiently.
The one thing I might wiggle on this one is for posting WIP in order to do the 'review early' bit. If that is already inferred here for others great, I didn't read it that way. dt -- Dean Troyer dtroyer@gmail.com
Thank you for the review and feedback. This is now on the wiki at https://wiki.openstack.org/wiki/StarlingX/Contribution_Guidelines Feedback/comments/edits encouraged and welcome! brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Tuesday, June 19, 2018 1:28 PM To: Jolliffe, Ian (Wind River) <ian.jolliffe@windriver.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 Tue, Jun 19, 2018 at 1:33 PM, Jolliffe, Ian <Ian.Jolliffe@windriver.com> wrote:
On 2018-06-15, 3:32 PM, "Jones, Bruce E" <bruce.e.jones@intel.com> wrote: Rule 1: We will follow all the usual open source and OpenStack conventions
IJ >> I would recommend we add some references. Did you have some in mind?
I've been saying we would fall back to OpenStack as a default in the absence of anything overriding. As we build our doc set adding references for things that both override or confirm those defaults would be useful.
Rule 2: Code submissions should do one thing. Larger efforts should be divided into multiple submissions.
IJ >> I could interpret this as a single function - isn't rule 3 sufficient and also, rule 1 or 7 should cover this. I suggest we remove and or combine with another line.
I think this is a distinct idea. A short review that does two things should be split. In the case of the upstream repos I will probably be noisy about this because of having to upstream things individually anyway.
Rule 4: Code submissions shall have a signed-off-by line. This is a strict requirement.
IJ >> I have done this in other projects, however, by using Gerrit we have the author and committer already noted. Does this not create confusion/duplication? Where would this signed-off-by line go - in the commit message?
"git commit -s" is sufficient. This requirement comes from the OpenStack project's intent to drop the CLA requirement in favor of DCO, and it seems like a simple thing to do from the start even if we don't have the same legal restrictions (I don't know if we do or not). LF was going to require it and enforce in Gerrit, we have that option if we want to use it.
Rule 6: Code submissions for bug fixes can be posted to gerrit when ready
IJ >> do we need a pointer/reference to a bug workflow? Openstack is moving toward Storyboard.
We are using only Storyboard where there is no intrinsic distinction between bugs and features.
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.
IJ >> this is a good practice and will help us work efficiently.
The one thing I might wiggle on this one is for posting WIP in order to do the 'review early' bit. If that is already inferred here for others great, I didn't read it that way. dt -- Dean Troyer dtroyer@gmail.com
participants (3)
-
Dean Troyer
-
Jolliffe, Ian
-
Jones, Bruce E