[6537] in Release_7.7_team
Collaboration document update
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Dec 3 15:13:55 2009
MIME-Version: 1.0
Date: Thu, 3 Dec 2009 15:13:45 -0500
Message-ID: <2706d8dd0912031213u33695336j42e6c67e8cfd84d8@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: release-team@mit.edu
Cc: debathena-dev@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
This is probably something that should have been sent before, but I
think we need to revisit the Debathena collaboration document.
In particular, I have issues with this part:
> 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
> exception. Time-sensitive security fixes are a good example of when
> this might be appropriate.
The last several times we've had to make exceptions for the 2-day
policy (usually for printing problems), we've never had the requisite
3 ACKs (we usually have 2 total developer ACKs + Jon). I think it's
pretty clear that this specific policy isn't working for us.
However, I do still think the goals behind the policy are valid. We've
repeatedly seen developers (well, ok, mostly me and geofft) screw up
uploads. On the other hand, we need a policy for deploying updates
quickly when necessary.
I don't think it's reasonable for us to say that the "developers
should be more careful," but we also can't have unfulfillable
requirements.
So does anybody have ideas for how we can allow for urgent updates
without sacrificing quality control?
- Evan
