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

Henrik Levkowetz <henrik@levkowetz.com> Tue, 16 May 2006 09:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvhx-0008Cf-Al; Tue, 16 May 2006 05:19:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvhw-0008CO-Ek; Tue, 16 May 2006 05:19:12 -0400
Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffvhv-0002Eh-1m; Tue, 16 May 2006 05:19:12 -0400
Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5E04837F28; Tue, 16 May 2006 11:19:10 +0200 (CEST)
Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 50BFF37E42; Tue, 16 May 2006 11:19:10 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A356437E52; Tue, 16 May 2006 11:19:05 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from <henrik@levkowetz.com>) id 1Ffvho-0005Of-PJ; Tue, 16 May 2006 11:19:05 +0200
Message-ID: <44699905.1090405@levkowetz.com>
Date: Tue, 16 May 2006 11:19:01 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
Subject: Re: [proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker
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>
In-Reply-To: <446980AD.7030200@zurich.ibm.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: Aaron Falk <falk@isi.edu>, Lisa Dusseault <lisa@osafoundation.org>, 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

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