geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sat, 01 Jul 2006 21:24:06 GMT

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.
> 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?
> 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.


View raw message