Re: commit fests

On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>>> Any ideas?
>
>> The lower bound on the release cycle is about 12 months right now
>> because we intend to support old versions for 5 years, and 5 or 6
>> branches at once is about the most anyone can handle.  That formula is
>> tough to change.
>
> Another problem is that it's very debatable whether users (as opposed
> to developers) want a fast release cycle.  Some of that reluctance to
> update might dissipate if we had a better upgrade-in-place story, but
> by no means all of it.  People don't want to have to retest their
> applications every six months.

I didn't mean to imply that we should try to release every 6 months,
if that's what it sounded like. I think annual release cycles are
fine. I don't like the idea of letting it slip to 15 or 18 months,
though.

> I agree with trying to cut down the submission-to-commit delay, but
> the release cycle length is not primarily determined by what patch
> authors would like ...

It seems to me that the CommitFest process is pretty darn effective at
reducing the submission-to-commit delay, except when you miss the last
one for the release - then it sucks hard.

I prefer annual release cycles as a user, not just as a developer. If
I start a new project now, it'll be based on 8.4.2. If 8.4 had never
happened and 8.3 were still the current release, any new project I
started would have to be based on 8.3. Of course, I still have
several systems running 8.3 (and I think even 8.2) that are chugging
along just fine; they lose nothing from 8.4 having been released.

...Robert