geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sun, 02 Jul 2006 01:52:54 GMT
Alan D. Cabrera wrote:
> 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 ( 
>> ).
>> On the same thread, Dain suggested introducing a "review-required" 
>> status in JIRA ( 
>> ) 
>> and is the method of tracking work that I prefer.
>> 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.
> I think that we only need a Review status.  But, in any case, Jira is 
> definitely the way to go.
>> 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
> Why should a patch that has been attached to a specific Jira issue 
> include the number of the jira issue?  I don't mind but it seems odd 
> and usually that means that I am misunderstanding something.
I was just trying to make it simpler for people so there is no confusion 
with what patch file they are working with once they save the patch to 
their PC from the JIRA issue. 

>> 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.
> There should be a way to enforce it.
>> 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)
>>     * 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".
> Just need to move it on to the regular Open status, no?
Thought it may be clearer to have a different status showing the review 
is complete and have the JIRA workflow match the true workflow.  For 
example if we were to move to open status after the review is complete, 
then the user would be given the opportunity to go back to 
review-required status, which isn't really a valid state transition, but 
maybe we should keep it simple and rely upon common sense?  Any JIRA 
experts out there who can comment on the benefits/disadvantages of 
having an additional review-complete status?


>> 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 
>> .
> This stuff sounds pretty cool.
> Regards,
> Alan

View raw message