Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing)
David Malcolm
dmalcolm at redhat.com
Wed Dec 13 20:49:06 UTC 2006
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20061213/e567ccdb/attachment.htm>
More information about the fedora-advisory-board
mailing list