Policy RFC: branches/2.0 change process

[Derek Atkins]

Quoting Josh Sled <jsled at asynchronous.org>:

> On Wed, 2006-07-12 at 14:54 -0400, Derek Atkins wrote:
>> 2) Any other changes must first be committed to trunk and then
>>    vetted/audited by at least one other developer before the changeset
>>    is "allowed" to be merged into branches/2.0.  In other words,
>>    developers should not commit code to the 2.0 release branch before
>>    another developer has "approved" the change.
>
> I don't think we need this for every commit, necessarily, so much as
> agreement to exercise restraint w.r.t. the branch, and to call for a
> review if a particular change warrants it.

My concern is that even small changes can introduce subtle bugs, so
by FORCING an audit on every change we can reduce the risk of a
collateral regression by a potentially non-obvious change (or even
an obvious change that has a subtle side-effect).

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available