I see the goals for "community releases" is that we can have a more coordinated cycle of development. We'd like to have predictable times when architecture and design changes are being made and others when we are stabilizing/fixing. I think that level of coordination would help use organize around stability and design movement windows.
That's a common practice for other projects. From: crowbar-bounces On Behalf Of ?????? ???? Sent: Friday, July 05, 2013 7:23 AM To: Terpstra, John Cc: crowbar Subject: Re: [Crowbar] Pull-Request Review and Merge Process >I. How should community code review discussions be conducted? >(Meetings, Conference calls, IRC, other) Code review in git comments is preferable. IRC is okay too, but git thould be more preferable. >II. Should the community create its own code releases >(independently from contributor organizations)? Well, if i properly understand the question - yes, for now keeping forked stable version of whole crowbar it is the only way to keep code, someone working on, in operational state and not to be interrupted when someone merged something that blew everything, even if it require a lot of work to merging back to upstream. >IV. How should SME appointments be handled? b. Organizational appointment? Good enought. 2013/6/29 <john_terps...@dell.com<mailto:john_terps...@dell.com>> I would like to initiate a discussion to secure an agreeable process for handling of pull-requests for the Crowbar community project. Please respond to this email with your suggestions, recommendations, and concerns. NOTE: The following are designed to initiate discussion - no decision has been made - nothing is locked in place by these proposals. Objectives: 1. To keep the public code tree in a clean and working condition 2. To facilitate the flow and processing of pull-requests 3. To avoid holding up the work of community developers 4. To encourage greater contribution 5. To provide a great experience for all code contributors and reviewers Proposed Process: a. All community participants/members are encouraged to provide patch (pull-request) feedback a. On the mailing list b. Over IRC channel #crowbar c. Via Github pull-request responses b. It is proposed that each participating organization is encourage to appoint a subject matter expert (SME) for each key area of the crowbar code base a. Responsibilities of the SME i. Top-level responsibility for code review and merging ii. Can assign responsibilities to a trusted fall-back person to ensure that pull-requests are not blocked when the SME is not available b. Assure that pull-requests are either handled (action is being taken) within 3 days of the submission i. Delegate to others to handle if the SME is unable to do it ii. Notify the Crowbar mailing list that of significant processing delays iii. Provide periodic feedback to the mailing list if a pull-request is held up c. Ensures that at least two (2) votes are received for each pull-request d. Maintains equitable behavior that does not impede code contribution work e. Liaises with SMEs within the community so that development work flows smoothly c. Code Review Cases a. Simple patch - action SME will merge the pull-request with minimum fuss i. No voting required ii. SME exercises total discretion b. Complex Pull-Request - patches are not potentially controversial i. SME seeks/waits for a minimum of two (2) votes [+1 == OK, 0 == Neutral, -1 == Blocks] ii. SME polls community for feedback is none is received within 48 hours iii. SME merges pull-request if no objections are received, closes pull-request at own discretion c. Potentially Controversial Patches i. SME refers the potential controversy to the community and engages the submitter to defend the case to merge ii. SME referees the resolution process d. Testing and Validation a. The SME will exercise sound judgment to determine the testing methodology that is appropriate to the patches submitted via the pull-request b. All contributors are expected to suggest/recommend the preferred method that is most appropriate to validate their pull-request/patches c. Code submissions are expected not to break the code Key Questions: I. How should community code review discussions be conducted? (Meetings, Conference calls, IRC, other) II. Should the community create its own code releases (independently from contributor organizations)? a. Should this be considered the formal community release? b. How should community release objectives be set? III. What criteria shall the community adopt in respect of pre-release code freeze, QA, etc.? a. What does a release cycle consist of? b. What influences release point goals, objectives, and their achievement? c. What should be the relationship between community releases and contributing organization releases? IV. How should SME appointments be handled? a. Community vote? b. Organizational appointment? c. How are individual contributor efforts protected in this structure? _______________________________________________ Crowbar mailing list Crowbar@dell.com<mailto:Crowbar@dell.com> https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
