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
