Thread: 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@gmail.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@gmail.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.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@momjian.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@momjian.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@gmail.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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@gmail.com> wrote: > On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.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@gmail.com> writes:
> On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Jul 27, 2010 at 4:48 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.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, 2010-07-27 at 14:11 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.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 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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@gmail.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