[Starlingx-discuss] Proposal: Basic development guidelines / rules

[Jolliffe, Ian]

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 at 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 at lists.starlingx.io
    http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss