On Monday 10 June 2002 02:46 pm, Marc G. Fournier wrote:
> Based on everything I've heard/seen in this thread, we seem to be looking
> at:
> 1. Branch on Sept 1st, regardless of almost anything
> 2. Once Branch created, any *partially implemented* features will get
> rip'd out of the -STABLE branch and only fixes to the existing, fully
> implement features will go in
> 3. Beta1 released once developers comfortable with the state of the code
> Now, *if*, the week before the Branch, someone submits a bit patch that in
> *anyway* concerns someone to apply, we can hold it off for a week and put
> it into the -DEV branch so that its not shelved for a couple of months,
> and possibly going out of date ... but that would be a judgement call at
> the time, nothing set in stone ...
> The only thing we are really "setting in stone" here is when we are
> branching/freezing the code for release ...
This seems to me to be reasonable. My only question would be 'why haven't we
always done it this way' but that isn't terribly productive. I actually know
the answer to my question, in fact, but that's not relevant to the future.
Many large projects do this, in some form or another. FreeBSD, Debian, even
the Linux kernel all follow this basic form.
Historically we've concentrated our development efforts during beta to 'fixing
beta problems only' -- but that model produces these extraordinarily long
cycles, IMHO. In the meantime people are literally chomping at the bit to do
a new feature -- to the point that one developer got rather upset that his
patch wasn't being looked at and 'stomped off' in a huff. All because we
were in beta-only mode.
However, I do think at that point we need to look at what the patch manager
(historically Bruce) can deal with realistically. Is it a job for two patch
managers, one for the STABLE and one for the DEV? Only Bruce can answer
whether he can realistically handle it (I personally have confidence he can).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
