geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Date Sat, 01 Jul 2006 05:24:19 GMT
> Ken suggested that we reintroduce the STATUS file as a way of  
> keeping track of the status of patches ( http://www.mail- 
> ).

-0, I'd rather not...

> On the same thread, Dain suggested introducing a "review-required"  
> status in JIRA ( 
> ) and is the method of tracking  
> work that I prefer.

+1, this is a good use of JIRA.

> 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:// 
> .

I think that it is a good idea to have a page like Derby does to  
provide bug/issue guide-lines.


View raw message