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

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Project scheduling issues (was Re: Per tuple overhead,
Date: 2002-06-10 19:54:13
Message-ID: 200206101554.13603.lamar.owen@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-06-10 19:57:15 Re: Bug #640: ECPG: inserting float numbers
Previous Message Bruce Momjian 2002-06-10 19:10:00 Re: Project scheduling issues (was Re: Per tuple overhead,