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
