[6540] in Release_7.7_team
Re: Collaboration document update
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Dec 3 15:31:15 2009
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.1.10.0912031523000.19246@dr-wily.mit.edu>
Date: Thu, 3 Dec 2009 15:31:06 -0500
Message-ID: <2706d8dd0912031231o515dd717pf06ff8b90b9854ff@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
Cc: release-team@mit.edu, debathena-dev@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
Content-Transfer-Encoding: 8bit
On Thu, Dec 3, 2009 at 3:23 PM, Tim Abbott <tabbott@mit.edu> wrote:
> On Thu, 3 Dec 2009, Tim Abbott wrote:
>
>> 2 developers + Support ACKing should be considered sufficient to ensure
>> reasonable quality control; maybe we should just adjust the rule to be
>> that.
>
> Er, I mean to allow that. 3 developers is probably also OK.
>
> -Tim Abbott
>
>
Yeah, I would basically be fine with that change. I guess I'll propose
a specific alteration for release-team's consideration:
diff --git a/collaboration.txt b/collaboration.txt
index c392b3e..0b38ac6 100644
--- a/collaboration.txt
+++ b/collaboration.txt
@@ -109,8 +109,8 @@ announced via one of the acceptable forums for
communication.
Exceptions can be made to the development process in cases where clear
consensus is reached that the exception should be made; this should
-involve an explicit approval from at least 3 developers, and from any
-other stakeholders who might have a particular interest in the
+involve an explicit approval from at least 3 stakeholders, including
+any stakeholders who might have a particular interest in the
exception. Time-sensitive security fixes are a good example of when
this might be appropriate.
- Evan
