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

From Heikki Linnakangas
Subject Re: 9.5 release scheduling (was Re: logical column ordering)
Date
Msg-id 5489F323.4080303@vmware.com
Whole thread Raw
In response to Re: 9.5 release scheduling (was Re: logical column ordering)  (Josh Berkus <josh@agliodbs.com>)
Responses Re: 9.5 release scheduling (was Re: logical column ordering)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: 9.5 release scheduling (was Re: logical column ordering)  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 12/11/2014 08:51 PM, Josh Berkus wrote:
> 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 UPSERT or GROUPING SETS?

No. I was thinking of patches like "Add IF NOT EXISTS to CREATE TABLE AS 
and CREATE MATERIALIZED VIEW", "event triggers: more DROP info", "Point 
to polygon distance operator" and "pgcrypto: support PGP signatures". 
And nobody was an exaggeration; clearly *someone* cares about those 
things, or they wouldn't have written a patch in the first place. But 
none of the committers care enough to pick them up. Even in the case 
that someone reviews them, it's often not because the reviewer is 
interested in the patch, it's just to help out with the process.

(Apologies to the authors of those patches; they were just the first few 
that caught my eye)

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

Yeah, there is that.

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

I was thinking that by getting candid feedback that none of the existing 
contributors are interested to look at your patch, the author could 
revise the patch to garner more interest, or perhaps promise to review 
someone else's patch in return. Right now, the patches just linger, and 
the author doesn't know why, what's going to happen or what to do about it.

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

Huh, I did? Can you elaborate?

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

I don't have any good solutions, I'm afraid. It might help to ping the 
reviewers who have signed up more often, to make the reviews to happen 
more quickly. I did some nudge people in the August commitfest, but I 
felt that it didn't actually achieve much. The most efficient way to 
move the commitfest forward was to just review more patches myself.

That's one thought. Robert said the same thing about when he was the 
commitfest manager; he just reviewed most the patches himself in the 
end. And you mentioned that Tom used to review 70% of all incoming 
patches. How about we make that official? It's the commitfest manager's 
duty to review all the patches. He can recruit others if he can, but at 
the end of the day he's expected to take a look at every patch, and 
commit or return with some feedback.

The problem with that is that we'll have a hard time to find volunteers 
for that. But we only need to find one sucker for each commitfest. I can 
volunteer to do that once a year; if the other active committers do the 
same, we're covered.

- Heikki




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Final Patch for GROUPING SETS
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching