On 12/11/2014 06:59 PM, Robert Haas wrote:
On Thu, Dec 11, 2014 at 11:03 AM, Tom Lane <t...@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.
There is a third option: reject more patches, more quickly, with less
discussion. IOW, handle new patches "less properly".
The commitfest is good at making sure that no patch completely falls off
the radar. That's also a problem. Before the commitfest process, many
patches were not actively rejected, but they just fell to the side if no
committer was interested enough in it to pick it up, review, and commit.
There are a lot of patches in the October commitfest that I personally
don't care about, and if I was a dictator I would just drop as "not
worth the trouble to review". Often a patch just doesn't feel quite
right, or would require some work to clean up, but you can't immediately
point to anything outright wrong with it. It takes some effort to review
such a patch enough to give feedback on it, if you want more meaningful
feedback than "This smells bad".
I imagine that it's the same for everyone else. Many of the patches that
sit in the commitfest for weeks are patches that no-one really cares
much about. I'm not sure what to do about that. It would be harsh to
reject a patch just because no-one's gotten around to reviewing it, and
if we start doing that, it's not clear what the point of a commitfest is
any more.
Perhaps we should change the process so that it is the patch author's
responsibility to find a reviewer, and a committer, for the patch. If
you can't cajole anyone to review your patch, it's a sign that no-one
cares about it, and the patch is rejected by default. Or put a quick
+1/-1 voting option to each patch in the commitfest, to get a quick
gauge of how the committers feel about it.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
