Re: commitfest.postgresql.org is no longer fit for purpose

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Friday, May 17, 2024, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> A solution to both of these issues (yours and mine) would be to allow
>> things to be added *during* the CF month. What is the point of having a
>> "freeze" before every CF anyway? Especially if they start out clean. If
>> something is ready for review on day 8 of the CF, why not let it be added
>> for review?

> In conjunction with WIP removing this limitation on the bimonthlies makes
> sense to me.

I think that the original motivation for this was two-fold:

1. A notion of fairness, that you shouldn't get your patch reviewed
ahead of others that have been waiting (much?) longer. I'm not sure
how much this is really worth. In particular, even if we do delay
an incoming patch by one CF, it's still going to compete with the
older stuff in future CFs. There's already a sort feature in the CF
dashboard whereby patches that have lingered for more CFs appear ahead
of patches that are newer, so maybe just ensuring that late-arriving
patches sort as "been around for 0 CFs" is sufficient.

2. As I mentioned a bit ago, the original idea was that we didn't exit
a CF until it was empty of un-handled patches, so obviously allowing
new patches to come in would mean we'd never get to empty. That idea
didn't work and we don't think that way anymore.

So yeah, I'm okay with abandoning the must-submit-to-a-future-CF
restriction.

regards, tom lane