Re: Project scheduling issues (was Re: Per tuple overhead, - Mailing list pgsql-hackers

Marc G. Fournier wrote:
> 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 ...

Not totally wrong.  I predict >90% of patches during those first two
weeks will have to be double-applied.  Do you disagree?  Remember, we
used to branch earlier and double-apply, and it did get confusing when
people forgot to double-patch.  I am not saying it is impossible, but I
don't want to minimize it either.


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

Yes, good point.  Developers are not testing.  However, when we do need
people to track down bugs and fixes, I hope they aren't too busy working
on new features to help us.

> *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?

Only bug fixes are going into 7.3 during beta, so how much is it going
to change?

And I have done the double-patching, so I remember the problems.  Aside
from the hassle of doing everything twice, as development drifts from
beta, the patches do become harder to apply.

> 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? :)

Yes, it will be good.

> 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

Now, that is an interesting idea.

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

OK.  I am making these points because the previous betas have been very
disorganized, with lots of wasted time.  I don't want it to happen
again.  We can't say we don't understand the issues.  It has happened so
many times that we are destined to repeat those problems unless we do
something differently.  Clearly, branch at beta, patch development tree,
disable partially implemented features, is a change.  I still think not
double patching for the first few weeks will be a win, though.

Remember, if you fix something in current, you have to generate a patch
and apply it to the STABLE tree for _anything_ you fix in stable.  And
almost any changes in STABLE have to be applied in current.  Also, bug
reports will have to indentify stable or development tree.

I know FreeBSD does it this way, but I don't hold them up as a model of
good organization.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026