Re: 9.5 release scheduling (was Re: logical column ordering) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: 9.5 release scheduling (was Re: logical column ordering)
Date
Msg-id CA+TgmoZpStX20Uk2-BjuQXtqhe0APf8nYaBxpvrjdcb6LV_Gpw@mail.gmail.com
Whole thread Raw
In response to Re: 9.5 release scheduling (was Re: logical column ordering)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 9.5 release scheduling (was Re: logical column ordering)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: 9.5 release scheduling (was Re: logical column ordering)  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Dec 11, 2014 at 11:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think 9.4 dragged almost entirely because of one issue: the
>> compressibility of JSONB.
>
> Meh.  While we certainly weren't very speedy about resolving that,
> I don't think that issue deserves all or even most of the blame.
> I agree with Josh: the problem really was that people were not focusing
> on getting 9.4 tested and releasable.  One way in which that lack of
> focus manifested was not having any urgency about resolving JSONB ...
> but it struck me as a systemic problem and not that specific issue's
> fault.
>
> I'd finger two underlying issues here:
>
> 1. As Bruce points out in a nearby thread, we've been in commitfest mode
> more or less continuously since August.  That inherently sucks away
> developer mindshare from testing already-committed stuff.

The problem is that, on the one hand, we have a number of serious
problems with things that got committed and turned out to have
problems - the multixact stuff, and JSONB, in particular - and on the
other hand, we are lacking in adequate committer bandwidth to properly
handle all of the new patches that come in.  We can fix the first
problem by tightening up on the requirements for committing things,
but that exacerbates the second problem.  Or we can fix the second
problem by loosening up on the requirements for commit, but that
exacerbates the first problem.  Promoting more or fewer committers is
really the same trade-off: if you're very careful about who you
promote, you'll get better people but not as many of them, so less
will get done but with fewer mistakes; if you're more generous in
handing out commit bits, you reduce the bottleneck to stuff getting
done but, inevitably, you'll be trusting people in whom you have at
least slightly less confidence.  There's an inherent tension between
quality and rate of progress that we can't get rid of, and the fact
that some of our best people are busier than ever with things other
than PostgreSQL hacking is not helping - not only because less actual
review/commit happens, but because newcomers to the community don't
have as much contact with the more senior people who could help mentor
them if they only had the time.

> 2. The amount of pre-release testing we get from people outside the
> hard-core development crowd seems to be continuing to decrease.
> We were fortunate that somebody found the JSONB issue before it was
> too late to do anything about it.  Personally, I'm very worried that
> there are other such bugs in 9.4.  But I've given up hoping that any
> more testing will happen until we put out something that calls itself
> 9.4.0, which is why I voted to release in the core discussion about it.
>
> I don't know what to do about either of those things, but I predict
> future release cycles will be just as bad unless we can fix them.

I agree.  We have had a few people, Jeff Janes perhaps foremost among
them, who have done a lot of really useful testing, but overall it
does feel pretty thin.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.5 release scheduling (was Re: logical column ordering)
Next
From: Robert Haas
Date:
Subject: Re: double vacuum in initdb