geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sun, 02 Jul 2006 01:37:40 GMT
AFAIK, it has never changed from having three binding +1 votes from the 
PMC, which is why there is an issue with a bottleneck processing RTCs 
due to the size of the PMC. 

It may not have been clearly communicated that that is how RTC works.

See Ken's comment in 
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html

Also see http://www.apache.org/foundation/voting.html where it says 
"Only votes by PMC members are considered binding on code-modification 
issues".

Made change below...

John

Alan D. Cabrera wrote:
> I don't understand how things changed from an RTC needing three +1 
> votes from other committers to three +1 votes from a PMC member.  Did 
> I miss an email that got sent out from the PMC?
>
>
> Regards,
> Alan
>
> John Sisson wrote:
>> One of the issues I see with the current process we have for changes 
>> under RTC is that it is hard to keep track of what patches are 
>> pending RTC.
>>
>> Ken suggested that we reintroduce the STATUS file as a way of keeping 
>> track of the status of patches ( 
>> http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).
>> On the same thread, Dain suggested introducing a "review-required" 
>> status in JIRA ( 
>> http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html ) 
>> and is the method of tracking work that I prefer.
>>
>> PROPOSAL
>>
>> 1. Add a "review-required" and "review-complete" statuses to JIRA. I 
>> thought having two statuses might allow a cleaner workflow in JIRA, 
>> but would be interested in hearing others opinions.
>>
>> 2. To make it easy for those reviewing and voting on the patches 
>> (there could end up being a number of revisions of the patch before 
>> it is accepted) the file names of the patches attached to the JIRA 
>> should be prefixed with the JIRA issue identifier followed by an 
>> optional text followed by a mandatory patch version number (starting 
>> at 1).
>> Example patch names:
>>
>>    GERONIMO-1234-FixNPE-v1
>>    GERONIMO-1234-FixNPE-v2 (second attempt at patch)
>>    GERONIMO-3421-v1
>>
>> 2.1 This status should only be set by a committer (can we can get 
>> JIRA to enforce this?) when they have tested the patch attached to 
>> the JIRA and believe it is ready for review. 2.2 The JIRA should 
>> contain all information about the patch.  If the changes were 
>> previously discussed on the dev list prior to the JIRA being created, 
>> a summary of the discussions should be moved into the JIRA so that 
>> those reviewing the patch have all the information in one place.  It 
>> would also be preferable to add links to the original discussions on 
>> the dev list archives.  The way  we document changes may be subject 
>> to change (e.g. detailed documentation placed in a linked JIRA) based 
>> upon the outcome of the discussions in the thread "[DISCUSS] Tracking 
>> documentation tasks in JIRA ( was Re: [RTC] Clarification please from 
>> the PMC )"
>>
>> 2.3 Each PMC member who reviews the patch attached to the JIRA must 
>> do the following:
>>     * Add a JIRA comment containing the file name of the patch they 
>> reviewed.  This is so there is no confusion if there ends up being 
>> multiple revisions of the patch when collating votes.
>>    * In the JIRA comment add the results of their review (e.g. 
>> comments or a vote).  If a PMC member vetos the patch, they must 
>> include a technical justification in their JIRA comments.  I propose 
>> that when there is a veto that we leave the status as 
>> "review-required", as others may still want to vote and so that the 
>> patch remains getting daily visibility in the "JIRAs Pending Review" 
>> daily email (proposed below).  The committer can then re-submit 
>> another patch (where the patch filename has the version number bumped 
>> up)
A committer could veto, but it wouldn't be binding, so the above 
paragraph should probably be changed to:

* In the JIRA comment add the results of their review (e.g. comments or 
a vote).  If a committer vetos the patch (note that only PMC votes are 
binding), they must include a technical justification in their JIRA 
comments.  I propose that when there is a veto that we leave the status 
as "review-required", as others may still want to vote and so that the 
patch remains getting daily visibility in the "JIRAs Pending Review" 
daily email (proposed below).  The committer can then re-submit another 
patch (where the patch filename has the version number bumped up)

>>     * If a PMC member is the person who completes the vote ( three 
>> binding +1s and no vetos) for the latest version of the patch then 
>> they should change the status to "review-complete".
>>
>> 3. Non-committers who submit patches will not be able to set this 
>> status.  A committer needs to pick up their patch and test it 
>> (possibly making changes to the patch).  When the patch is ready the 
>> committer then sets the "review-required" status.
>>
>> 4. Have a daily email automatically sent to the dev list containing 
>> JIRA's pending review.  It appears this should be easy to implement 
>> as it would be a variation of the weekly "Unassigned Patches" reports 
>> that are currently in place.
>> I would be interested in your comments Jason, as you are more 
>> familiar with customizing JIRA.
>>
>> If this proposal is accepted I will document it as part of the work I 
>> plan to do to document the use of JIRA in 
>> http://issues.apache.org/jira/browse/GERONIMO-2080 .
>>
>> John
>>
>>
>
>


Mime
View raw message