[sldev] 1.18.2.1 source code

[Joshua Bell]

Callum Lerwick wrote:
> On Mon, 2007-09-24 at 13:51 -0700, Joshua Bell wrote:
>   
>> Part of the point of the RC process is to avoid introducing new bugs. 
>>     
>
> What I'd like to see from the "RC" process, is a feature freeze. Whats
> in stays in, whats out stays out. Bugfix only.
>   
Exactly.

(Well, not just feature freeze - bugfix freeze too apart from newly 
introduced regressions. There's no distinction from the code perspective 
- any bugfix is as likely to destabilize the code as a feature change of 
the same magnitude. We have a ton of additional bug fixes waiting in the 
wings - see the "release" code drops - but pulling them into the RC 
would destabilize it tool.)

The down side is a potentially vicious circle: If it consistently takes 
a long time to stabilize a release, the number of pending changes 
waiting for the next release piles up. And the more changes that go into 
a release, the longer it'll take to stabilize. Which can lead to a 
temptation to take shortcuts around the process.

(I suspect that this is mitigated in either a smaller development team 
or in the classic boxed-software waterfall development cycle - during 
the stabilization phase, everyone is doing nothing but stabilization. In 
our case, the incoming bug rate is low enough that most developers are 
unblocked and continuing to work on other bugfix work or features. As 
the user base increases this may change.)

Any help we can get in triaging and fixing bugs identified during the RC 
process will go a LONG way to maintaining the process and the stability 
of the codebase, by showing the value of the process in consistent 
quality and more predictable dates.