geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sun, 02 Jul 2006 23:50:56 GMT
Alan D. Cabrera wrote:
> John Sisson wrote:
>> Alan D. Cabrera wrote:
>>> John Sisson wrote:
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>>
>>>>> John Sisson wrote:
>>>>> <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.
>> 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).
>
> Ok, so the "In Progress" state will go off of Open state.  I guess 
> that the idea of the reviewed state for the actual patch application.  
> Please note that I have removed the Reopened state.  It seemed 
> superfluous.
>
>> A JIRA issue may also be created for a bug and bug fixes do not need 
>> to go through the RTC process.
>
> Yeah, we can use the current process for that.
>
>> 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 programatically.
>
> I had intended to restrict it.  Do you think that it would be useful 
> to always be able to move back to a RTC voting stage?  When would we 
> need to do that after approval?
How did you intend to restrict it?

There is a possibility that that the developer of the patch or another 
developer could discover an issue with the patch after it has been 
approved but before it was committed and wants to revise the patch and 
go through the review again.  Should we allow transitions from the 
review and reviewed states to the Open state to cater for this type of 
situation (it may take the developer a couple of weeks to rework the 
patch before they want it reviewed again, so won't want it showing up in 
the RTC reports)?

Thanks,
John
>
>
> Regards,
> Alan
>
>
>
> ------------------------------------------------------------------------
>


Mime
View raw message