Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing)

[David Malcolm]

[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