[apologies for the HTML email, ran afoul of a bug in an old version of evolution; hopefully this one will come through as text] On Tue, 2006-12-12 at 17:37 -0500, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > > > January 02 is probably to hard to reach, so we should cut one cycle from > > four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > The reverse-chronological list above defines some dates for releases of things that might be called "deliverables". These deliverables are currently all software trees. Is it possible to add the high-level objectives for what a release might contain as the first deliverable? - integrate Core and Extras - orbital laser integrated into GUI control system - integrate lobby-buddy [1] throughout the distro - reduce the bootup time - attempt to fix system services - enhanced, integrated bling for the desktop - static analysis for the whole distro or whatever... (currently the only thing I know of for F7 is the first one) We'd then put time in at the top of the schedule to try to define these high-level themes for F7. So the list of deliverables (in forward chronological order) might look like this: - Jan 1st: roadmap for release (features, high-priority bugs, fallback plans in case things aren't going to land in time) - [ Period of time where development happens, testers try to figure out how to test things, and rawhide eats people's branes ] - January 30: Test1 - February 27: Test2 - April 17: Gold - April 24: Release - party - May 7th: post-mortem report (feeding into the roadmap for the next release) IMHO the only way we can get whole-distribution improvements rather than incremental changes here and there is to try to define and aim for them at the start of a development cycle. Thoughts? Dave [1] https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00032.html _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
