db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Proposed JIRA workflow changes
Date Wed, 01 Jun 2005 16:49:24 GMT
Hi, all.  I think Kathey has brought up a good point about managing the 
status of patches.  A regular email I see is "has anyone looked at this 
patch??".  I think Kathey is not the only one who is not clear on what 
patches need reviewing, who is already looking at them, and which ones 
have just fallen through the cracks.

It is my understanding that a Derby member with the appropriate rights 
can adjust the workflow of Jira to add new states.  This seems like the 
perfect place to apply that.  Under that assumption, I would like to 
propose an updated workflow for a Derby item.  This new workflow 
requires two new states to Derby JIRA: "Patch Submitted" and "Reviewed".

I'd like us to seriously consider something like this, otherwise we will 
continue to be swimming in patches with no clear sense of what is going 
on.  I for one do not want to maintain an ongoing list of the status of 
patches, this would be an ongoing and time-consuming task.  This should 
be a self-directed, distributed process that can scale up as we grow.


- An item is assigned to a developer.  The item is marked as In Progress 
when the developer is actively working on it, otherwise it is marked as 

- Prior to submitting a patch, the developer *must* run
   o svn update (resolving any merge issues)
   o ant clobber
   o ant all
   o run suite derbyall and verify that any failures are clearly 
unrelated to the current patch

- The developer submits the patch by attaching it to the JIRA item and 
marking the item status as *Patch Submitted*.

- The developer sends an email to the list identifying a particular 
person they want to review a patch.  Two or more developers may want to 
adopt a "buddy" relationship so that they agree to review each others' 
patches.  But the main point is you don't just "hope" someone will 
review the patch.  It is more than fine if more than one person reviews 
a patch, but one person must have the specific responsibility of 
reviewing it.

- When a reviewer accepts this responsibility, the item is assigned to 
the person reviewing the patch.  This allows developers to know what 
patches they are responsible for reviewing.

- If the patch passes review, and the reviewer is also a committer, the 
item is committed and marked as *Resolved* and reassigned to the 
original developer.

- If the reviewer is not a committer, the item is marked as *Reviewed* 
and re-assigned to the original developer.

- If the patch does not pass, the item is marked as *Open* and it is 
reassigned to the original developer.  The developer continues to rework 
the patch until it passes review successfully.

- If the patch is reviewed but not committed, the developer contacts a 
specific committer and asks them to commit the patch.  If the committer 
declines, the developer continues to ask committers until someone 
accepts to commit the patch.  Once a committer accepts to commit the 
patch, it is assigned to them.  This allows committers to know what 
patches they are responsible for committing.

- If the patch is successfully committed, it is marked as *Resolved* and 
the item is reassigned to the *original reporter* of the item.  This way 
reporters know which bugs they need to verify and close.

- If it could not be committed, the item is reassigned to the developer 
and the state is marked as *Open*.  In most cases the developer should 
have the patch re-reviewed before it is committed.

- Once an item is committed, the reporter then verifies the item was 
fixed to their satisfaction and marks it as closed.  If it does not pass 
verification, it is marked as Open and reassigned to the original developer.




View raw message