Re: 9.5 release scheduling (was Re: logical column ordering)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: 9.5 release scheduling (was Re: logical column ordering)
Дата
Msg-id CA+TgmoZpStX20Uk2-BjuQXtqhe0APf8nYaBxpvrjdcb6LV_Gpw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.5 release scheduling (was Re: logical column ordering)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 9.5 release scheduling (was Re: logical column ordering)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: double vacuum in initdb