Robert Haas <robertmh...@gmail.com> writes: > On Fri, May 17, 2024 at 9:54 AM Joe Conway <m...@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