[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 

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.


[1] https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00032.html
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]