[Fwd: Re: Schedule figures]

[John Poelstra]

-------- Original Message --------
Subject: Re: Schedule figures
Date: Tue, 23 Sep 2008 16:28:10 -0700
From: John Poelstra <poelstra at redhat.com>
To: Paul W. Frields <stickster at gmail.com>
CC: rel-eng at fedoraproject.org, Tom 'spot' Callaway 
<tcallawa at redhat.com>,  Bill Nottingham <notting at redhat.com>
References: <1222199081.16833.31.camel at victoria-eth.internal.frields.org>

Paul W. Frields said the following on 09/23/2008 12:44 PM Pacific Time:
> Ladies and gentlemen,
> 
> We're at a point where our GA date currently rests at 4 weeks total slip
> from our original date, and we're still trying to get a working Beta
> AIUI.  About 3 weeks of that slip are due to the intrusion -- this
> thread is simply about schedule concerns.  We should start thinking now
> about how we can properly take up the slack from the F10 release
> schedule in F11 and F12.
> 
> I think if I were to informally poll everyone, they'd agree that we
> can't suck up 4 weeks of development time in the F11 schedule alone.
> Here are some ideas to consider (please add your concerns, and pose a
> solutions to address them):

I don't think we need to change the F11 or F12 schedules.  This keeps us
consistent with our stated objective of releasing every six months. I
don't think we need to change the F11 GA date unless there is a major
compelling feature that needs time to develop that cannot wait for
F12... but that would go against our stated objective of being a time
based release.

We can achieve this by shortening the development window and following
the rest of the standard task durations for F11.  To me this follows the
line of thinking people have been trying convince me of for a long time
which is basically that our releases are "just snapshots of rawhide".
That being the case, a shortened development window for one release
shouldn't matter that much because it isn't finished it can just join
the next release.

This also avoids the ripple affect of pushing out the GA date of F11 or
F12... you always have to absorb it somewhere so why not just get it
over with in the F11 development cycle?

> * Move all dates in the current F11 schedule to the right by two weeks
> (i.e. absorb two weeks of slip).  Similarly absorb remaining two weeks
> of slip into the F12 schedule.  Further slip will move both F11 and F12
> schedules to the right accordingly.
> 
> * Rigorously enforce freezing in a way that maximizes our chances of
> turning out test releases on time.
> 

It seems to me that rigorous freezes are only as good as rigorous
testing because you don't know how good or bad the stuff you've frozen
is until you test it.

John