Return-Path: 
 <dev-return-32922-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 92333 invoked from network); 2 Jul 2006 23:52:33 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 2 Jul 2006 23:52:33 -0000
Received: (qmail 3114 invoked by uid 500); 2 Jul 2006 23:52:27 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 3068 invoked by uid 500); 2 Jul 2006 23:52:27 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 3056 invoked by uid 99); 2 Jul 2006 23:52:27 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Jul 2006 16:52:26 -0700
X-ASF-Spam-Status: No, hits=0.5 required=10.0
	tests=DNS_FROM_RFC_ABUSE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of jrsisson@gmail.com designates
 64.233.166.179 as permitted sender)
Received: from [64.233.166.179] (HELO py-out-1112.google.com) (64.233.166.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Jul 2006 16:52:24 -0700
Received: by py-out-1112.google.com with SMTP id e30so1238208pya
        for <dev@geronimo.apache.org>; Sun, 02 Jul 2006 16:51:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=irlyP1Ugioa+JHFV+9PROjEcy7v6v1zXaUC3frsAdNjDF9lU0qAKrgZCOqp1Ohi6OD1kvnDmkeTDP2iz+j1kYzsgJduGY8MtolMrWai/nfmYtMaBkuWL0s8ITpQ/91eDrEbN3pWps3OK4jSsi8qfgvIYB6+Rw0PA4Pw1g+RUojI=
Received: by 10.35.98.6 with SMTP id a6mr738666pym;
        Sun, 02 Jul 2006 16:51:30 -0700 (PDT)
Received: from ?218.185.73.243? ( [218.185.73.243])
        by mx.gmail.com with ESMTP id k53sm1652483pyd.2006.07.02.16.51.29;
        Sun, 02 Jul 2006 16:51:30 -0700 (PDT)
Message-ID: <44A85BE0.4010005@gmail.com>
Date: Mon, 03 Jul 2006 09:50:56 +1000
From: John Sisson <jrsisson@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: [Proposal] Tracking the status of patches under RTC (was Re:
 [RTC] Clarification please from the PMC)
References: <44A5D680.6060208@gmail.com> <44A6E7F6.7030606@toolazydogs.com>
 <44A726F6.5080103@gmail.com> <44A800B8.1090907@toolazydogs.com>
 <44A84B5D.8080902@gmail.com> <44A85387.3080009@toolazydogs.com>
In-Reply-To: <44A85387.3080009@toolazydogs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Alan D. Cabrera wrote:
> John Sisson wrote:
>> Alan D. Cabrera wrote:
>>> John Sisson wrote:
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>>
>>>>> John Sisson wrote:
>>>>> <snip>
>>>>> Lots of process...
>>>>> </snip>
>>>>>
>>>>>>>>     * If a PMC member is the person who completes the vote ( 
>>>>>>>> three binding +1s and no vetos) for the latest version of the 
>>>>>>>> patch then they should change the status to "review-complete".
>>>>>>> Just need to move it on to the regular Open status, no?
>>>>>> Thought it may be clearer to have a different status showing the 
>>>>>> review is complete and have the JIRA workflow match the true 
>>>>>> workflow.  For example if we were to move to open status after 
>>>>>> the review is complete, then the user would be given the 
>>>>>> opportunity to go back to review-required status, which isn't 
>>>>>> really a valid state transition, but maybe we should keep it 
>>>>>> simple and rely upon common sense?  Any JIRA experts out there 
>>>>>> who can comment on the benefits/disadvantages of having an 
>>>>>> additional review-complete status?
>>>>> mmm, ok.  I'm sold.
>>>>>
>>>>> I'm a Jira admin so I have dug up the work flow that we're 
>>>>> currently using.  Here's what I think we're proposing.
>> Thanks for creating the diagrams Alan.
>>
>> Currently one can create "Open" a JIRA issue and start working on it, 
>> optionally marking it as "In Progress" as you showed below in your 
>> first diagram.  In your second diagram this won't be possible.  The 
>> JIRA should be able to be worked on prior to RTC (and hopefully will 
>> be discussed on the dev list with the developer community before it 
>> gets to the RTC phase).
>
> Ok, so the "In Progress" state will go off of Open state.  I guess 
> that the idea of the reviewed state for the actual patch application.  
> Please note that I have removed the Reopened state.  It seemed 
> superfluous.
>
>> A JIRA issue may also be created for a bug and bug fixes do not need 
>> to go through the RTC process.
>
> Yeah, we can use the current process for that.
>
>> I assume we would always allow the user to move to the Review state 
>> (no matter what their issue type is) rather than trying to restrict 
>> it programatically.
>
> I had intended to restrict it.  Do you think that it would be useful 
> to always be able to move back to a RTC voting stage?  When would we 
> need to do that after approval?
How did you intend to restrict it?

There is a possibility that that the developer of the patch or another 
developer could discover an issue with the patch after it has been 
approved but before it was committed and wants to revise the patch and 
go through the review again.  Should we allow transitions from the 
review and reviewed states to the Open state to cater for this type of 
situation (it may take the developer a couple of weeks to rework the 
patch before they want it reviewed again, so won't want it showing up in 
the RTC reports)?

Thanks,
John
>
>
> Regards,
> Alan
>
>
>
> ------------------------------------------------------------------------
>