Re: Feature Freeze date for 8.4

On Mon, 2007-10-22 at 23:36 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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".

Yes, I think so.

> But this cycle was clearly
> mismanaged. It's not productive to have a freeze this long.

That's a good starting point. We need to be objective about what worked
and what didn't.

I'm very happy about the way we handled performance in this release. We
took time to measure things, analyse the problems and then fix them with
new code that hadn't even been envisaged before FF. So I'd suggest we
have formal phase in the process *after* the code has been fully
integrated where we can measure performance and tune anything we need
to.

> [ 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 be happy with that approach.

My feeling is there is more than one problem that is being discussed
here. Some developers have complained that it sometimes takes a long
time to get a patch reviewed and committed. Committers are clearly
swamped by the volume of patches and we need to avoid another FF peak.

Generally, the project does a good job of committing work as it arrives.
Some patches do get missed and so the transit time through the patch
queue can be very long in some cases.

I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
a "patch queue blitz" where we stop developing and reduce the queue to
nothing. Perhaps a two-week period where everybody helps reduce the
queue, not just Tom and Bruce. Every outstanding patch gets told what
they need to do in order to get it committed. FF is then just the last
in a series of checkpoints. Suggest we do a checkpoint every 2 months.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com