Tom, all: > > 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. > > I like this idea ...
This would also avoid some bit-rot. However, I'd suggest every 6 weeks; every 2 months would only cycle 2-4 times during a development cycle, and every month would be too frequently. So, say that 8.4 dev officially began on December 1, it would be: Dec 1 - Jan 1: development Jan 1 - Jan 14: queue blitz Jan 15 - Feb 14: development Feb 15 - Feb 28: queue blitz ... June 1: Final patch deadline, 100% stable except for performance/docs, or you wait for 8.5. The other thing we really really need to make this work is *tracking*. For example, I have access to performance and quality testing resources at Sun, but it needs to be crystal clear to my team which patches are ready for testing, where to get them, how to apply them, and what to test. And it can't be dependant on reading 100 e-mail messages a day and filtering for that information the way it currently is. So we should start doing Stefan's patch grid from day 1 of 8.4, and all patch submitters should register with developer.postgresql.org and keep their patch information updated. Do we have any way to upload patch files to the wiki? If not, where can we put them? Or do we want to do a real patch manager? -- Josh Berkus PostgreSQL @ Sun San Francisco ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
