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