On 5/16/24 22:26, Robert Haas wrote:
For example, imagine that the CommitFest is FORCIBLY empty
until a week before it starts. You can still register patches in the
system generally, but that just means they get CI runs, not that
they're scheduled to be reviewed. A week before the CommitFest,
everyone who has a patch registered in the system that still applies
gets an email saying "click here if you think this patch should be
reviewed in the upcoming CommitFest -- if you don't care about the
patch any more or it needs more work before other people review it,
don't click here". Then, the CommitFest ends up containing only the
things where the patch author clicked there during that week.
100% agree. This is in line with what I suggested on an adjacent part of
the thread.
The point is - we need a much better signal to noise ratio here. I bet
the number of patches in the CommitFest that actually need review is
something like 25% of the total. The rest are things that are just
parked there by a committer, or that the author doesn't care about
right now, or that are already being actively discussed, or where
there's not a clear way forward.
I think there is another case that no one talks about, but I'm sure
exists, and that I am not the only one guilty of thinking this way.
Namely, the week before commitfest I don't actually know if I will have
the time during that month, but I will make sure my patch is in the
commitfest just in case I get a few clear days to work on it. Because if
it isn't there, I can't take advantage of those "found" hours.
We could create new statuses for all of those states - "Parked", "In
Hibernation," "Under Discussion," and "Unclear" - but I think that's
missing the point. What we really want is to not see that stuff in
the first place. It's a CommitFest, not
once-upon-a-time-I-wrote-a-patch-Fest.
+1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
