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 Re: Proposed JIRA workflow changes
Date Wed, 01 Jun 2005 17:09:24 GMT
I'd like to add that we can improve the process immediately without 
having to wait for the JIRA changes, by

   (a) contacting a *specific* person to review and to commit a patch and
   (b) re-assigning items to the person responsible for the next step in 
the lifecycle of the item, so that an individual can easily determine 
what they are responsible for.


David Van Couvering wrote:

> 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 
> *Open*.
> - 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.
> ==== END PROPOSAL ===
> Thanks,
> David

View raw message