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

On 12/11/2014 09:22 AM, Heikki Linnakangas wrote:

> 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.

So the "nobody cares" argument is manifestly based on false assumptions.Are you contending that nobody cares about
UPSERTor GROUPING SETS?  In
 
my experience, the patches that sit for weeks on the CF fall into 4 groups:

1. Large complicated patches that only a handful of committers are even
capable of reviewing.

2. Obscure patches which require specialized knowledge our outside input
to review.

3. Inconsequential patches where the submitter doesn't work the social
process.

4. Patches with contentious spec or syntax.

5. Patches which everyone wants but have persistent hard-to-resolve issues.

Of these only (3) would fit into "nobody cares", and that's a pretty
small group.

There's also a chicken-and-egg problem there.  Say that we started not
reviewing DW features because "nobody cares".  Then the people who
contributed those features don't go on to become major contributors,
which means they won't review further DW patches.  Which means that
we've just closed off an entire use-case for PostgreSQL.  I'd think that
PostGIS would have taught us the value of the "nobody cares" fallacy.

Also, if we go back on the promise that "every patch gets a review",
then we're definitely headed towards no more new contributors.  As Noah
said at one developer meeting (to paraphrase), one of the few things
which keeps contributors persisting through our baroque,
poorly-documented, excessively political contribution process is the
promise that they'll get a fair shake for their invested time.  If we
drop that promise, we'll solve our workflow problem by cutting off the
flow of new patches entirely.

> 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.

Again, that process would favor existing contributors and other folks
who know how to "work the Postgres community".  It would be effectively
the same as hanging up a sign which says "no new contributors wanted".
It would also be dramatically increasing the amount of politics around
submitted patches, which take up far more time than the technical work.

Overall, we're experiencing this issue because of a few predictable reasons:

1. a gradual increase in the number of submitted patches, especially
large patches

2. Tom Lane cutting back on the number of other people's patches he
reviews and revises.

3. Other major committers getting busier with their day jobs.

4. Failure to recruit, mentor and promote new committers at a rate
proportional to the number of new contributors or the size of our community.

5. Failure to adopt or develop automated systems to remove some of the
grunt work from patch submission and review.

6. Failure to adhere to any uniform standards of patch handing for the
Commitfests.

(2) out of these is actually the biggest thing we're seeing right now, I
think.   Tom was historically a one-man-patch-fixing machine, at one
time responsible for 70% of the patches committed to PostgreSQL.  This
was never a good thing for the community, even if it was a good thing
for the code base, becuase it discouraged others from stepping into a
senior committer role.  Now Tom has cut back, and others have to take up
the slack.  In the long run this will be good for our development
community; in the short run it's kind of painful.

I will also point out that some of the existing senior committers, who
are the heaviest burdened under the existing system, have also been the
most resistant to any change in the system.  You (Heikki) yourself
expressed a strong opposition to any attempt to recruit more reviewers.
So, given that you are inside the heart of the problem, do you have a
solution other than your proposal above that we simply stop accepting
new contributors?  Or is that your solution?  It would work, for some
definition of "work".

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com