From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new commitfest transition guidance |
Date: | 2025-02-27 17:03:48 |
Message-ID: | CA+TgmobQXQ5R-sNT7UsAdOMn-mBhHni0aULcJikQG8dARRLs1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 27, 2025 at 11:14 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > But let's not make the mistake of saying "we're not going to move
> > things automatically because we want to find out if the authors are
> > still interested" and then getting really concerned when some stuff
> > doesn't get moved. That's missing the whole point.
>
> +1. Having a significant fraction of patches drop off the radar
> was the desired outcome, wasn't it?
Well, not if the authors really are still actively caring about them.
But there's been a funny evolution of our thinking about CommitFests
over the years. When I first started managing CommitFests, I evicted
patches that the author didn't update -- following a review -- within
four days. Not four business days - four calendar days. After all, it
was a CommitFest -- it was supposed to be for patches that were ready
to be committed. That policy was, I think, viewed by many as too
draconian, and it probably was. But now we've gotten to a point where
the one month gap between CommitFest N and CommitFest N+1 is thought
to be so short that it might be unreasonable to expect a patch author
to move their patch forward sometime during that time. And I think
that's clearly going too far the other way.
Perhaps even way, way too far the other way. I think it's completely
fine if somebody has a patch that they update occasionally as they
have and it putters along for a few years and it finally either gets
committed or it doesn't. I one hundred percent support part-time
developers having the opportunity to participate as and when their
schedule permits and I think that is an important part of being a good
and welcoming open source community. But there are also people who are
working very hard and very actively to progress patches and staying on
top of the CF status and any new review emails every day, and that is
ALSO a great way to do development, and it's reasonable to treat those
cases differently. I'm not sure exactly how we can best do that, but
it makes my head hurt every time I find something in the CF where the
patch author was like "well, I'll get back to this at some point" and
then three CFs later it's still sitting there in "Needs Review" or
something.
Probably not moving things forward automatically is only one part of
that problem -- we could very much use some better tooling for judging
how active certain patches are and, if not so active, whether that's
more a lack of reviewers or more author inactivity. But we're not
doing ourselves any favors by working super-hard to keep everything
that anybody might potentially care about in the same bucket as things
that are actually active.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2025-02-27 17:32:28 | Re: Confine vacuum skip logic to lazy_scan_skip |
Previous Message | Dave Page | 2025-02-27 16:56:05 | Licence preamble update |