Re: do we need to postpone beta4?

I think we should consider postponing beta4. I count eleven
non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there
are currently five items on the open 9.0 issues list, at least one of
which appears to be a new bug in 9.0, and we just got a bug report on
pgsql-bugs from Valentine Gogichashvili complaining of what looks to
be a crasher in the redo path for heap_xlog_update(). It seems
unlikely at this point that we can have all of these issues fixed and
still have time for a full buildfarm cycle before the wrap. Does it
make sense to put out a beta with known bugs (presumably requiring
another beta) at this point, or should we push this off a bit?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think we should consider postponing beta4. I count eleven
> non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there
> are currently five items on the open 9.0 issues list, at least one of
> which appears to be a new bug in 9.0, and we just got a bug report on
> pgsql-bugs from Valentine Gogichashvili complaining of what looks to
> be a crasher in the redo path for heap_xlog_update(). It seems
> unlikely at this point that we can have all of these issues fixed and
> still have time for a full buildfarm cycle before the wrap. Does it
> make sense to put out a beta with known bugs (presumably requiring
> another beta) at this point, or should we push this off a bit?

If we don't wrap a beta this week, the next possible window is several
weeks away, because various people will be on vacation. So I think we
should get the existing fixes out there, even if there are known bugs
remaining. A beta is not an RC.

regards, tom lane

On Tue, 2010-07-27 at 14:11 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I think we should consider postponing beta4. I count eleven
> > non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there
> > are currently five items on the open 9.0 issues list, at least one of
> > which appears to be a new bug in 9.0, and we just got a bug report on
> > pgsql-bugs from Valentine Gogichashvili complaining of what looks to
> > be a crasher in the redo path for heap_xlog_update(). It seems
> > unlikely at this point that we can have all of these issues fixed and
> > still have time for a full buildfarm cycle before the wrap. Does it
> > make sense to put out a beta with known bugs (presumably requiring
> > another beta) at this point, or should we push this off a bit?
>
> If we don't wrap a beta this week, the next possible window is several
> weeks away, because various people will be on vacation. So I think we
> should get the existing fixes out there, even if there are known bugs
> remaining. A beta is not an RC.

If we document the bugs, then +1, if we don't -1. E.g; we let people
know where we KNOW there are warts.

JD

>
> regards, tom lane
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think we should consider postponing beta4.  I count eleven
>> non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there
>> are currently five items on the open 9.0 issues list, at least one of
>> which appears to be a new bug in 9.0, and we just got a bug report on
>> pgsql-bugs from Valentine Gogichashvili complaining of what looks to
>> be a crasher in the redo path for heap_xlog_update().  It seems
>> unlikely at this point that we can have all of these issues fixed and
>> still have time for a full buildfarm cycle before the wrap.  Does it
>> make sense to put out a beta with known bugs (presumably requiring
>> another beta) at this point, or should we push this off a bit?
>
> If we don't wrap a beta this week, the next possible window is several
> weeks away, because various people will be on vacation.  So I think we
> should get the existing fixes out there, even if there are known bugs
> remaining.  A beta is not an RC.

Well, that's pretty much saying we won't release before September.
Which is kind of a bummer, but I guess that's what happens when we get
into vacation season.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas wrote:
> On Tue, Jul 27, 2010 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> I think we should consider postponing beta4. ?I count eleven
> >> non-documentation, 9.0-specific bug fix on REL9_0_STABLE, but there
> >> are currently five items on the open 9.0 issues list, at least one of
> >> which appears to be a new bug in 9.0, and we just got a bug report on
> >> pgsql-bugs from Valentine Gogichashvili complaining of what looks to
> >> be a crasher in the redo path for heap_xlog_update(). ?It seems
> >> unlikely at this point that we can have all of these issues fixed and
> >> still have time for a full buildfarm cycle before the wrap. ?Does it
> >> make sense to put out a beta with known bugs (presumably requiring
> >> another beta) at this point, or should we push this off a bit?
> >
> > If we don't wrap a beta this week, the next possible window is several
> > weeks away, because various people will be on vacation. ?So I think we
> > should get the existing fixes out there, even if there are known bugs
> > remaining. ?A beta is not an RC.
>
> Well, that's pretty much saying we won't release before September.
> Which is kind of a bummer, but I guess that's what happens when we get
> into vacation season.

Yeah, if we are lucky we can do RC1 in mid-August and still release
final in August, but that assumes everything is done by then, and that
we only need 1-2 RCs. Early September looks more likely. The good
thing is that we are deciding now and are continually seeing if we can
tighten the schedule. (If we stop trying to tighten the schedule, we
get a lose schedule, which no one likes.)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Tue, Jul 27, 2010 at 3:53 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Well, that's pretty much saying we won't release before September.
>> Which is kind of a bummer, but I guess that's what happens when we get
>> into vacation season.
>
> Yeah, if we are lucky we can do RC1 in mid-August and still release
> final in August, but that assumes everything is done by then, and that
> we only need 1-2 RCs.  Early September looks more likely.  The good
> thing is that we are deciding now and are continually seeing if we can
> tighten the schedule.  (If we stop trying to tighten the schedule, we
> get a lose schedule, which no one likes.)

I am assuming that if we release beta4 with known bugs, beta5 in
mid-August is inevitable. And we're going to need at least a couple
of weeks after beta5 before RC1, even assuming no new issues come up.
ISTM that if everything goes well we can expect to release in
*mid*-September.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Well, that's pretty much saying we won't release before September.

Yup, that's what I think. In fact I think September might be
optimistic. This is what happens when you fork early and allow
developers to start focusing on new development instead of testing
the release branch.

> Which is kind of a bummer, but I guess that's what happens when we get
> into vacation season.

Yes. If we were at full strength maybe August would be make-able, but
there are too many people on vacation right now, and way too many
distractions to boot.

In any case, now that 9.0 is branched there is not any
project-scheduling reason why the final release needs to happen any
particular time. I think we need to fall back on our traditional mantra
"we'll release it when it's ready" rather than fret about whether it's
August or September or whatever.

regards, tom lane

On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, that's pretty much saying we won't release before September.
>
> Yup, that's what I think.  In fact I think September might be
> optimistic.  This is what happens when you fork early and allow
> developers to start focusing on new development instead of testing
> the release branch.

I call bullshit. The six items in the "code" section of the open
items list were reported 14, 5, 5, 1, 27, and 0 days ago. The 27-day
old item is purely cosmetic and there's absolutely zero evidence that
Simon hasn't done it yet because he's been busy working on 9.1
development. It's much more likely that he hasn't gotten around to
taking care of that (and his outstanding 9.1 patch) because he's been
busy with everything else in his life other than pgsql-hackers. The
remaining items have an average age of precisely 5 days, which hardly
sounds like we've been sitting on our hands, especially when you
consider that both you and Heikki have been on vacation for longer
than that. And it's not as if I haven't been following those issues,
either. Had you and Heikki and Peter fallen down a well more or less
permanently, I would have patched about half of those bugs by now.
The fact that I haven't done so is not because I'm busy working on 9.1
development, but because I respect your expertise and wish to have the
benefit of it so as to reduce the chances that I will break things,
or, for that matter, fix them in a way that's adequate but not the one
you happen to prefer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Well, that's pretty much saying we won't release before September.
>>
>> Yup, that's what I think.  In fact I think September might be
>> optimistic.  This is what happens when you fork early and allow
>> developers to start focusing on new development instead of testing
>> the release branch.
>
> [poorly worded protest]

Sorry - I apologize for that email. As has been pointed out to me
off-list, that was too strongly worded and not constructive. Still, I
don't think there is much evidence for the proposition that the
current delays are caused by having branched early. I think they're
caused by people being out of town.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Yup, that's what I think. In fact I think September might be
>>> optimistic. This is what happens when you fork early and allow
>>> developers to start focusing on new development instead of testing
>>> the release branch.

>> [poorly worded protest]

> Sorry - I apologize for that email. As has been pointed out to me
> off-list, that was too strongly worded and not constructive. Still, I
> don't think there is much evidence for the proposition that the
> current delays are caused by having branched early. I think they're
> caused by people being out of town.

Well, they're surely both contributing factors. There's no way to run a
controlled experiment to determine how much each one is hurting us, so
opinions about which is worse can never be more than opinions. I'm
sticking with mine though, and for weak evidence will point to the
amount of -hackers traffic about 9.1 CF items versus the amount of
traffic about how to fix the known bugs.

Anyway, I'm back from vacation and will start looking at those bugs as
soon as I've caught up on email.

regards, tom lane

On Tue, Jul 27, 2010 at 6:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Yup, that's what I think.  In fact I think September might be
>>>> optimistic.  This is what happens when you fork early and allow
>>>> developers to start focusing on new development instead of testing
>>>> the release branch.
>
>>> [poorly worded protest]
>
>> Sorry - I apologize for that email.  As has been pointed out to me
>> off-list, that was too strongly worded and not constructive.  Still, I
>> don't think there is much evidence for the proposition that the
>> current delays are caused by having branched early.  I think they're
>> caused by people being out of town.
>
> Well, they're surely both contributing factors.  There's no way to run a
> controlled experiment to determine how much each one is hurting us, so
> opinions about which is worse can never be more than opinions.  I'm
> sticking with mine though, and for weak evidence will point to the
> amount of -hackers traffic about 9.1 CF items versus the amount of
> traffic about how to fix the known bugs.

I guess I'd counter by pointing out that there are half a dozen bugs
and almost 70 patches in the CommitFest. And, again, it's not as if
bugs are sitting there being ignored for months on end. To the
contrary, we've been largely ignoring new patches for the past five
months, but we rarely ignore bugs. When 2 or 3 days go by without a
response to a serious bug report, people start posting messages like
"Hello? Hello? What's going on?" (there are several examples of this
in just the last week, from at least two different contributors).

> Anyway, I'm back from vacation and will start looking at those bugs as
> soon as I've caught up on email.

Thanks. Let me know if I'm not picking up something you think I
should be looking at. I've been attempting to stay on top of both bug
reports and the CommitFest in your absence, which has been keeping me
extremely busy, which may account for some portion of the testiness of
my previous response.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, that's pretty much saying we won't release before September.
>
> Yup, that's what I think.  In fact I think September might be
> optimistic.  This is what happens when you fork early and allow
> developers to start focusing on new development instead of testing
> the release branch.

Actually, rewind. I see that you moved the user-mappings issue I was
concerned about to "resolved after beta3"; I missed the fact that
you'd committed a fix there. You also fixed the EPQ issue, and the
heap_update_redo problem evaporated. So now we have the following
issues remaining:

* page corruption after moving tablespace
* ExplainOnePlan handles snapshots differently than ProcessQuery
* name and comment of XLogSetAsyncCommitLSN() should be changed
* Documentation fails to build as PDF

...and I wouldn't necessarily regard any of those as forcing another
beta; the first two are ancient, the third is cosmetic, and the last
one is a build system issue rather than a code change.

Obviously, it's too early to decide anything: we may yet discover more
issues that need to be addressed. But I think we're in much better
shape than it seemed 24 hours ago.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> So now we have the following issues remaining:

> * page corruption after moving tablespace
> * ExplainOnePlan handles snapshots differently than ProcessQuery
> * name and comment of XLogSetAsyncCommitLSN() should be changed
> * Documentation fails to build as PDF

> ...and I wouldn't necessarily regard any of those as forcing another
> beta; the first two are ancient, the third is cosmetic, and the last
> one is a build system issue rather than a code change.

> Obviously, it's too early to decide anything: we may yet discover more
> issues that need to be addressed. But I think we're in much better
> shape than it seemed 24 hours ago.

Yeah. I'm off poking at the "incorrect FTS result" problem, but that
is a pre-existing bug as well; it goes back at least to 8.4 and probably
further.

regards, tom lane