Skip site navigation (1) Skip section navigation (2)

Re: damage control mode

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, David Fetter <david(at)fetter(dot)org>
Subject: Re: damage control mode
Date: 2010-01-10 10:31:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Jan 10, 2010 at 08:09, Robert Treat
<xzilla(at)users(dot)sourceforge(dot)net> wrote:
> On Sunday 10 January 2010 01:38:07 Tom Lane wrote:
>> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
>> > ... I don't see much sense in worrying about it now; the 2 weeks between
>> > end of CF and Beta are when we need to be cut-throat. Given that this
>> > time the "must-have" feature is already in the tree, I think you will
>> > find people coming around quickly to the side of pushing things out
>> > rather than fighting to get things in.
>> I think the other Robert's main point is that getting to beta in only
>> two weeks is ridiculously optimistic (which I'm afraid I agree with).
>> I believe that what he's proposing is tossing enough stuff overboard
>> so that we can finish the January CF in much less than a month, and
>> thereby have more time for alpha-level testing and stabilization of
>> the tree.
> I agree with your summary, although I'm not sure it needs to be supported at
> this point. While it hasn't been stated explicitly, I suspect most reviewers
> will be reviewing with the idea of "is there any chance that this is ready for
> commit" in the back of thier heads, and things that aren't will likely get
> pushed off quickly.

So how about we make that explicitly stated?

>> Now the other approach we could take is that we'll ship *something*
>> on 7 Mar, even if it's less stable than what we've traditionally
>> considered to be beta quality.  I don't think that really helps
>> much though; it just means we need more time in beta.
> There are three reasons I'd probably be comfortable with that; 1) the CF
> process means we've likely had more eyes on the code going in than in past
> releases. 2) the alpha releases mean we should have already had more review
> than in previous releases. 3) so far we're still looking good on pg_migrator,
> which should make it easier for people to test the release once we get into
> beta (which should help speed that cycle up).

1 is hopfully right. 2 should be, but we haven't received many bug
reports for people with the alphas. Which certainly *could* mean that
1 made there not be many bugs, but it could also mean that people
aren't really testing it, just tasting it.

> But really if beta slips because we don't like the looks of our open issues
> list, thats signicantly better than the last couple releases where we held
> everything up just to get things into CVS months after feature freeze had
> passed us by.

It is, unless it's because we created those open items by committing
things too late in the cycle, even though it wasn't quite ready, "so
the author won't have to wait another year for a release".

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2010-01-10 11:09:05
Subject: Re: We need to rethink relation cache entry rebuild
Previous:From: Magnus HaganderDate: 2010-01-10 10:29:03
Subject: Re: damage control mode

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group