Re: Project scheduling issues (was Re: Per tuple overhead,

On Mon, 10 Jun 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > Agreed on all accounts ... which is why this time, I want to do a proper
> > > branch when beta starts ... hell, from what I've seen suggested here so
> > > far, we have no choice ... At least then we can 'rip out' something from
> > > the beta tree without having to remove and re-add it to the development
> > > one later, hoping that they're changes haven't been affected by someone
> > > else's ...
> >
> > Well, let's give that a try and see how it goes.  I'm a bit worried
> > about the amount of double-patching we'll have to do, but other projects
> > seem to manage to cope with multiple active branches...
>
> Yes, Marc has been advocating this, and perhaps it is time to give it a
> try.  There are some downsides:
>
>     o All committers need to know that they have to double-patch

*Wrong* .. only if its a fix for a problem with -STABLE .. otherwise it
*just* goes in the development tree ...

>     o We might have developers working on new features rather than
>       focusing on beta testing/fixing.

Its not the developers responsibility to beta test the software, its is
their responsibility to test patches as they are applied during the
'development cycle' ... and even after we've branched in the past, ppl
have "fixed reported bugs" and applied such fixes to the -STABLE branch
... why would that be any different now?  All we're doing is letting
developers work on their projects instead of sitting on their hands
waiting for a bug report ...

*Plus* ... good chance that any bugs that are reports are in the -DEV
branch also, so it has to be fixed regardless ...

> One interesting idea would be to create a branch for 7.4, and apply
> _only_ 7.4 patches to that branch.  Then, when we release 7.3, we merge
> that branch back into the main CVS tree.  That would eliminate
> double-patching _and_ give people a place to commit 7.4 changes.  I
> don't think the merge would be too difficult because 7.3 will not change
> significantly during beta.

Four words: when hell freezes over

Why must you overcomplicate a process most *large* projects seem to find
sooooo simple to deal with?  God, what you are proposing above requires
ppl to predict what v7.3 is going to look like when its finished, so that
their work on v7.4 can follow?

Bruce, I think this whole thread has just about dried up now ... when v7.3
goes beta, we will branch just like other large projects do so that we
don't hold up any developers until we release the software, which, based
on past experiences and history, will end up being delayed ... hell, just
think, we branch on the 1st of Sept, release on the 15 of October (lets
say one month for beta plus a bit of delay), and are ready to go with the
next beta around the 1st of January since we did't lose that 1.5mo of
development time ... wow, imagine a *solid* 4 month development cycle
before beta? :)

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
tothe 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 ...