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.
=== PROPOSED CHANGE TO JIRA ITEM WORKFLOW ====
- 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
