Re: [proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker

Lisa Dusseault <lisa@osafoundation.org> Tue, 16 May 2006 17:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg37V-0003fe-LC; Tue, 16 May 2006 13:14:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg37U-0003fP-Eu; Tue, 16 May 2006 13:14:04 -0400
Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg37U-0002HN-3D; Tue, 16 May 2006 13:14:04 -0400
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21BD4142289; Tue, 16 May 2006 10:13:59 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17146-10; Tue, 16 May 2006 10:13:58 -0700 (PDT)
Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1993614226D; Tue, 16 May 2006 10:13:58 -0700 (PDT)
In-Reply-To: <44699905.1090405@levkowetz.com>
References: <E1FdpF4-0007xU-Fk@megatron.ietf.org> <446715D7.7080701@zurich.ibm.com> <446726DE.8040904@levkowetz.com> <44673AB3.2050002@zurich.ibm.com> <4467436E.2060400@levkowetz.com> <A9A5C496-4C40-43F8-86C7-8EC882AF85D9@osafoundation.org> <4468F2AA.60707@levkowetz.com> <446980AD.7030200@zurich.ibm.com> <44699905.1090405@levkowetz.com>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <93BF5579-D718-4C3E-A3E1-A44F04C87769@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker
Date: Tue, 16 May 2006 10:13:55 -0700
To: Henrik Levkowetz <henrik@levkowetz.com>
X-Mailer: Apple Mail (2.749.3)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: Aaron Falk <falk@isi.edu>, Brian E Carpenter <brc@zurich.ibm.com>, iesg@ietf.org, proto-team@ietf.org, mankin@psg.com
X-BeenThere: proto-team@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process and Tools Team <proto-team.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proto-team@ietf.org>
List-Help: <mailto:proto-team-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=subscribe>
Errors-To: proto-team-bounces@ietf.org

Why would this have to be sub-states?  Why not just a state of  
"Document in external review" and the comments (or a review announce  
form) can indicate who the review request was sent to?

Trying to simplify, so if this isn't a real simplification, feel free  
to ignore.

thx,
Lisa

On May 16, 2006, at 2:19 AM, Henrik Levkowetz wrote:

> Hi Brian,
>
> on 2006-05-16 09:35 Brian E Carpenter said the following:
>> Henrik Levkowetz wrote:
> ...
>>>
>>> I think that with no constraint on the amount of change we could
>>> introduce I'd advocate a fairly complete set of explicit review
>>> actions, and the possibility of setting more than one sub-state
>>> at the same time.  Then it's easy for other tools to pick up the
>>> sub-state and use that to trigger other actions.  Any free-form
>>> field makes that much harder and less predictable; and reducing
>>> all the states to very generic ones makes it impossible to kick
>>> off a particular review dispatch from the state change.
>>>
>>> Whether we have the option to include this in the work package I
>>> don't know, however.
>>
>> I would hate the result to be that the tracker artificially
>> serializes reviews.
>>
>> I think that you should include the requirement, but with
>> flexibility for the implementor. If handling multiple parallel
>> review-waits is a challenge, the fallback as you say is annotation.
>> (You already have "5 reviews" as a substate. I was wondering
>> how that was going to be handled, except by annotation.)
>
> How about adding this at the end of Section 3.1:
>
>    "In several cases, such as for the 'WG Document Awaiting Reviews'
>    state, it is highly desirable to be able to set multiple sub-states
>    at the same time (R-013).  This is in order to avoid  
> serialisation of
>    reviews because the tracker doesn't support showing and indicating
>    parallel reviews."
>
>
> ?
>
>
> 	Henrik
>
>


_______________________________________________
proto-team mailing list
proto-team@ietf.org
https://www1.ietf.org/mailman/listinfo/proto-team