On Mon, 2007-10-22 at 23:36 -0400, 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".
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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
