geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sat, 01 Jul 2006 01:57:20 GMT
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.

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-v2 (second attempt at patch)

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)
     * 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 .


View raw message