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 Mon, 03 Jul 2006 03:01:19 GMT
John Sisson wrote:
> 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?

By just simply limiting the transitions.  Anything else would require us 
dropping a plugin into the Jira server.

> 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 

Ok, so every state should have a transition to go back to Open?


Regards,
Alan




Mime
View raw message