geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sun, 02 Jul 2006 17:22:00 GMT
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 ( 
>>> 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.
>> 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







Mime
View raw message