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 Mon, 03 Jul 2006 07:33:11 GMT
Alan D. Cabrera wrote:
> 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?
>
I think that would allow the most flexibility.

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


Mime
View raw message