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