Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
I'd settle for your earlier slightly porous formulation, at least for
one go round. We don't seem very fond of hard and fast rules as a
community (c.f. txid controversy) :-) The target should be to get to
beta within about a month from feature freeze, I think.
Maybe we need a better triage at the start of feature freeze which gives
candidates a preliminary review, at least enough to say "this is/is not
very close to being able to be applied". Anything that isn't, even if
submitted well before freeze, misses out. If reviewers are more active
then the candidate list would be small.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?