Re: Triage on old commitfest entries - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Triage on old commitfest entries
Date
Msg-id CAH2-WzmVQA-xNcUdUKgEyifPOMJKMpOuMBWmC79AyBSNHSwKcg@mail.gmail.com
Whole thread Raw
In response to Re: Triage on old commitfest entries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Triage on old commitfest entries  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sun, Oct 3, 2021 at 1:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm, perhaps.  You're right that the classification might be slippery.
> I do feel it's useful to distinguish "this is a bad idea overall,
> we don't want to see follow-on patches" from "this needs work, please
> send a follow-on patch when you've done the work".  But maybe more
> thought could get an idea out of the first category and into the
> second.

I agree in principle, but experience suggests that there is
approximately zero practical difference.

My whole approach is to filter aggressively. I can only speak for
myself, but I have to imagine that this is what most committers do, in
one way or another. I am focussed on what I can understand with a high
degree of confidence, that seems likely to be relatively beneficial to
users -- nothing more. So patch authors that receive no feedback from
me ought to assume that that means absolutely nothing, even in areas
where my input might be expected. I'm not saying that I *never*
mentally write-off patches without saying anything, but it's rare, and
when it happens it tends to be in the least interesting, most obvious
cases -- cases where speaking up is clearly unnecessary. I would hate
to think that less experienced patch authors are taking radio silence
as a meaningful signal, whether it's from me or from somebody else --
because it's really not like that at all.

My argument boils down to this: I think that less experienced
contributors are better served by a system that plainly admits this
uncertainty. At the same time I think that old patches need to get
bumped for the good of all patch authors collectively. We have a hard
time bumping patches today because we seem to feel the need to justify
it, based on facts about the patch. The reality has always been that
Postgres patches are rejected by default, not accepted by default. We
should be clear about this.

> Fair.  My concern here is mostly that we not just keep kicking the
> can down the road.  If we see that a patch has been hanging around
> this long without reaching commit, we should either kill it or
> form a specific plan for how to advance it.

Also fair.

The pandemic has made the kind of coordination I refer to harder in
practice. It's the kind of thing that face to face communication
really helps with.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Adding CI to our tree
Next
From: Mark Dilger
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations