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