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 ).
-0, I'd rather not...
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.
+1, this is a good use of JIRA.
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.
Well, I guess it depends on how permanent the RTC rules are... making
changes to use additional statues means modification of the project's
workflow. Unfortunately changing the workflow in JIRA is not a
trivial task, and will have large affects over all issues in the
project. For example, if we introduce new statues, then remove them
later, the state of the issues associated with those states is lost.
But if we do want new statues... there are already these statues in
JIRA (used by Derby):
* Patch Available
* Patch Reviewed
* Patch Revised
* Patch Finalized
If this is going to be more temporary in nature, then it might make
more sense to create a new JIRA project to hold these issues and
workflow configuration, which would leave the other projects unchanged.
We'd probably have to create a new project anyways to setup and test
the configuration, since to validate and apply the workflow it must
be attached to the project... but when attached it can not be edited,
so you have to keep attaching and detaching the workflow to get
things modified.
And in the end we may end up wanting to keep this new project around
to help manage votes/reviews on other stuff too.
* * *
On the other-hand... it is much easier to add a new field to a
project, which can be a combo list which could be something like:
Review Status:
* Required
* Accepted
* Rejected
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
This is generally a good idea, RTC or not.
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.
JIRA can enforce this... BUT, not very easily. Using the workflow
impl it is possible to only allow members of a group to trigger the
transition... not sure if the version of JIRA that the ASF is running
can do this though.
We can always write a plugin to implement the behavior we want, but
this is also troublesome as it will require getting ASF Infra
involved to reconfigure and redeploy JIRA with our plugin.
IMO, while it is possible to get the tool to do this, it is much less
painful to just make the management of setting these states to be a
human process. It would be nice if JIRA was more friendly at helping
to implement this type of functionality though...
3. Non-committers who submit patches will not be able to set this
status. A committer needs to pick up their patch and test it
(possibly making changes to the patch). When the patch is ready
the committer then sets the "review-required" status.
Should be able to control this by groups and screens (depending on if
a status or field).
I would be interested in your comments Jason, as you are more
familiar with customizing JIRA.
IMO, using the workflow is probably the right way to implement
this... but harder. Custom field is easier... but less than ideal.
I recommend we create a new JIRA project, configure that projects
workflow to implement the procedure and then see how well it works
out. As I mentioned before, this project could also be used to track
other non-RTC voting too.
Come to think of it... we might even want to introduce a new Issue
type for RTC and/or Vote.
If this proposal is accepted I will document it as part of the work
I plan to do to document the use of JIRA in http://
issues.apache.org/jira/browse/GERONIMO-2080 .
I think that it is a good idea to have a page like Derby does to
provide bug/issue guide-lines.
--jason
