Re: Feature Freeze date for 8.4

Tom Lane wrote:
> 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.
>   

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.


cheers

andrew