Re: Feature Freeze date for 8.4
От | Tom Lane |
---|---|
Тема | Re: Feature Freeze date for 8.4 |
Дата | |
Msg-id | 3518.1193110560@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Feature Freeze date for 8.4 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Feature Freeze date for 8.4
(Andrew Dunstan <andrew@dunslane.net>)
Re: Feature Freeze date for 8.4 ("Joshua D. Drake" <jd@commandprompt.com>) Re: Feature Freeze date for 8.4 (Gregory Stark <stark@enterprisedb.com>) Re: Feature Freeze date for 8.4 (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Before we settle on any dates I think we should have some discussion > about how we can shorten the period between feature freeze and beta, > which was far too long this time. Perhaps we need to be more aggressive > about what what makes the cut and what doesn't. I think basically we need to redefine "feature freeze". The definition we effectively used for the last couple of cycles was "if you've posted a patch, even a slushy one, by the stated FF date, you make the cut". This was compounded in the 8.3 cycle by reviewers (and I'm looking at myself here) figuring that we could postpone reviewing patches until after FF because the policy didn't require that they be in good shape *before* that date. That would've worked OK if there were only a few such patches, but we had a lot of big ones. If we want a short FF-to-beta period then the criterion will have to be that patches are either committed or darn near ready to commit on the FF date. No springing mostly-done patches on the community a few days before FF. And the reviewers will need to work harder on reviewing stuff earlier, and committing before FF whenever possible. And we need to be much more ready to bounce stuff that's not quite done, rather than drag out the cycle to let it get finished. No, it doesn't sound like any fun :-(. But this cycle was clearly mismanaged. It's not productive to have a freeze this long. [ thinks for a bit... ] A truly hard-nosed approach would be to define FF as "if your patch isn't committed by the FF date, you lose". The FF-to-beta delay then is only long enough to make sure we've documented everything, written release notes, etc. I'm not sure this would be a more pleasant way to work, as there'd be a heck of a lot of pressure on the committers as the days tick down to FF. But it'd fix the scheduling problem. regards, tom lane
В списке pgsql-hackers по дате отправления: