Alan D. Cabrera wrote:
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
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).
A JIRA issue may also be created for a bug and bug fixes do not need to
go through the RTC process.
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.
Thanks,
John
------------------------------------------------------------------------
