Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 17, 2024 at 9:54 AM Joe Conway <mail@joeconway.com> wrote:
>> I agree with you. Before commitfests were a thing, we had no structure
>> at all as I recall. The dates for the dev cycle were more fluid as I
>> recall, and we had no CF app to track things. Maybe retaining the
>> structure but going back to the continuous development would be just the
>> thing, with the CF app tracking just the currently (as of this
>> week/month/???) active stuff.
> The main thing that we'd gain from that is to avoid all the work of
> pushing lots of things forward to the next CommitFest at the end of
> every CommitFest.
To my mind, the point of the time-boxed commitfests is to provide
a structure wherein people will (hopefully) pay some actual attention
to other peoples' patches. Conversely, the fact that we don't have
one running all the time gives committers some defined intervals
where they can work on their own stuff without feeling guilty that
they're not handling other people's patches.
If we go back to the old its-development-mode-all-the-time approach,
what is likely to happen is that the commit rate for not-your-own-
patches goes to zero, because it's always possible to rationalize
your own stuff as being more important.
> Like, we could also just have a button that says "move everything
> that's left to the next CommitFest".
Clearly, CFMs would appreciate some more tooling to make that sort
of thing easier. Perhaps we omitted it in the original CF app
coding because we expected the end-of-CF backlog to be minimal,
but it's now obvious that it generally isn't.
BTW, I was reminded while trawling old email yesterday that
we used to freeze the content of a CF at its start and then
hold the CF open until the backlog actually went to zero,
which resulted in multi-month death-march CFs and no clarity
at all as to release timing. Let's not go back to that.
But the CF app was probably built with that model in mind.
regards, tom lane