Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <429E05C1.3040600@Sourcery.Org>
Date: Wed, 01 Jun 2005 12:00:17 -0700
From: Satheesh Bandaram <satheesh@Sourcery.Org>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Proposed JIRA workflow changes
References: <429DE714.8030207@sun.com> <429DEBC4.4080307@sun.com>
In-Reply-To: <429DEBC4.4080307@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


David Van Couvering wrote:

> 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

I am not sure if this is a good idea. That specific person may not have
expertise in that area of code or may be on vacation or busy with other
activities. We are all supposed to be "volunteers" in open source world,
right? I do agree patches not getting reviewed in time is a problem.
This problem usually gets worse close to a release, as everyone is busy
addressing their "itches".

>   (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.

Well... This may not work, if the person is off on vacation or busy with
some other activities.

Satheesh

> David
>
> 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.
>>
>> === 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
>
>
>
>