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 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

Reply via email to