Re: 8.4 release planning

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, jd(at)commandprompt(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.4 release planning
Date: 2009-01-27 06:15:04
Message-ID: 497EA668.9020307@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule wrote:
> 2009/1/27 Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>:
>> On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> so it could be released. 8.5 should be implemented in shorted
>>> cycle - only one commitfest, that is enough (+3 month) for well
>>> completing SE and replication patches.
>> we tried this before (8.2 to 8.3 i think), the idea was that the next
>> release should be in 6 months... we release at least 6 months later...
>>
>> ATM that a new release cycle starts new patch will arrive and there
>> will be no way to get the shorted release in time...
>
> I remember it. Solution is - don't accept new patches for next commitfest.

I don't think that'll work. People will still keep writing patches. Or
if they don't, that's even worse! Either people will work on patches
that they're interested in, or they'll go away and do something else.
Only very few will drop their pet projects for the common good and help
with the review instead.

We can adjust the length of the release cycle by adjusting the number of
commitfests. I think the normal ~ 1 year cycle is quite optimal, though.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-01-27 06:19:13 Re: 8.4 release planning
Previous Message Brendan Jurd 2009-01-27 06:09:19 Re: Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)