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 22:40:29 GMT
Alan D. Cabrera wrote:
> John Sisson wrote:
>> 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.
> Cool, makes sense, but let's not make it a hard and fast rule.
>>>> 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.
> <snip>
> Lots of process...
> </snip>
>>>>     * 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?
> mmm, ok.  I'm sold.
> I'm a Jira admin so I have dug up the work flow that we're currently 
> using.  Here's what I think we're proposing.
> Regards,
> Alan
Thanks for creating the diagrams Alan.

Currently one can create "Open" a JIRA issue and start working on it, 
optionally marking it as "In Progress" as you showed below in your first 
diagram.  In your second diagram this won't be possible.  The JIRA 
should be able to be worked on prior to RTC (and hopefully will be 
discussed on the dev list with the developer community before it gets to 
the RTC phase).

A JIRA issue may also be created for a bug and bug fixes do not need to 
go through the RTC process.

I assume we would always allow the user to move to the Review state (no 
matter what their issue type is) rather than trying to restrict it 

> ------------------------------------------------------------------------

View raw message