Re: commitfest.postgresql.org is no longer fit for purpose - Mailing list pgsql-hackers

From Robert Haas
Subject Re: commitfest.postgresql.org is no longer fit for purpose
Date
Msg-id CA+TgmoZKgd27w9soHAy1TBfnWy2iAwk5uCz_4hV=NLe1+O31Wg@mail.gmail.com
Whole thread Raw
In response to Re: commitfest.postgresql.org is no longer fit for purpose  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: commitfest.postgresql.org is no longer fit for purpose
Re: commitfest.postgresql.org is no longer fit for purpose
Re: commitfest.postgresql.org is no longer fit for purpose
List pgsql-hackers
On Fri, May 17, 2024 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > We already have gone back to that model. We just haven't admitted it
> > yet. And we're never going to get out of it until we find a way to get
> > the contents of the CommitFest application down to a more reasonable
> > size and level of complexity. There's just no way everyone's up for
> > that level of pain. I'm not sure not up for that level of pain.
>
> Yeah, we clearly need to get the patch list to a point of
> manageability, but I don't agree that abandoning time-boxed CFs
> will improve anything.

I'm not sure. Suppose we plotted commits generally, or commits of
non-committer patches, or reviews on-list, vs. time. Would we see any
uptick in activity during CommitFests? Would it vary by committer? I
don't know. I bet the difference wouldn't be as much as Tom Lane would
like to see. Realistically, we can't manage how contributors spend
their time all that much, and trying to do so is largely tilting at
windmills.

To me, the value of time-based CommitFests is as a vehicle to ensure
freshness, or cleanup, or whatever word you want to do. If you just
make a list of things that need attention and keep incrementally
updating it, eventually for various reasons that list no longer
reflects your current list of priorities. At some point, you have to
throw it out and make a new list, or at least that's what always
happens to me. We've fallen into a system where the default treatment
of a patch is to be carried over to the next CommitFest and CfMs are
expected to exert effort to keep patches from getting that default
treatment when they shouldn't. But that does not scale. We need a
system where things drop off the list unless somebody makes an effort
to keep them on the list, and the easiest way to do that is to
periodically make a *fresh* list that *doesn't* just clone some
previous list.

I realize that many people here are (rightly!) concerned with
burdening patch authors with more steps that they have to follow. But
the current system is serving new patch authors very poorly. If they
get attention, it's much more likely to be because somebody saw their
email and wrote back than it is to be because somebody went through
the CommitFest and found their entry and was like "oh, I should review
this". Honestly, if we get to a situation where a patch author is sad
because they have to click a link every 2 months to say "yeah, I'm
still here, please review my patch," we've already lost the game. That
person isn't sad because we asked them to click a link. They're sad
it's already been N * 2 months and nothing has happened.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: commitfest.postgresql.org is no longer fit for purpose
Next
From: Robert Haas
Date:
Subject: Re: commitfest.postgresql.org is no longer fit for purpose