On 5/17/24 09:08, Peter Eisentraut wrote:
On 17.05.24 14:42, Joe Conway wrote:
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.
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?
Maybe this all indicates that the idea of bimonthly commitfests has run
its course. The original idea might have been, if we have like 50
patches, we can process all of them within a month. We're clearly not
doing that anymore. How would the development process look like if we
just had one commitfest per dev cycle that runs from July 1st to March 31st?
What's old is new again? ;-)
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.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
