The slip down memory lane

[Toshio Kuratomi]

I'll reply here but I'm also bringing together some things in the rest of
the thread... sorry about that.

On Thu, Aug 12, 2010 at 01:19:29PM -0500, Mike McGrath wrote:
> 
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice).  Lets not yell, lets not flame war, lets not
> point fingers.  How can we fix this?  It's clearly not one group or one
> individual or we'd just go talk to them.  This is a collective failure.
> 
I think there's several ways to look at this:

0) Acknowledge that slips are going to happen and worry about other things.
   In the end, no one can beat Murphy.

1) Anticipate that slips are going to happen.  Alternatives to work with
   this but still give ourselves a better chance of hitting an overall
   schedule:

1.1) If we think that any given release is going to slip by one month, then
     we should add a month between the time we compose the final bits and
     the availability of the release. Options for what we do if we don't use
     all the slip time:

1.1.1) As slips happen, we can eat into this time.  The object of the game
       here is *to release early*.  ie: we want to try not to eat into our
       one month window to slip but if we do, then we've already planned for
       it.

1.1.2) As slips happen, we can eat into this time.  But if we get the final
       release done ahead of schedule we delay the release until our
       pre-announced release date.

Option 1.2) Build the slip time into the milestones.  Say we anticipate we
        could slip by a month.  Add one week between the compose of the
        Alpha milestone and the release of Alpha, two weeks between the
        compose of the Beta and the release of the beta, and two weeks
        between the final compose and the release.  Slips can eat into those
        weeks without impacting the next milestone.  Slips that take up more
        than the allotted time for that milestone slip the whole release
        schedule.

2) Decide that we know better than Murphy and we can build a product without
   slips:

2.1) Have releng put a lock on the packageset earlier and more rigourously.
     For instance, move the Alpha change deadline where releng stops pushing
     packages unless they know what it will affect back to coincide with
     Feature Freeze.  Move the FInal Change Deadline a week closer to the
     Beta release.  Etc.

Three notes:

1) I'm not a big fan of #2.  Trying to cheat Murphy is a losing proposition.
Working with Murphy to remain flexible is a much better idea.

2) Option #1 does not specify an exact time frame.  We could get this by
adding extra time to the release cycle.  We could also get it by taking the
slip time away from the other portions of the release.  (ie: take a week
away from development during the alpha nad a week away from development
during the beta and use those as a two week slip time for the final
release).

3) This comes at a cost.  The cost is that the bits that we end up shipping
won't be as fresh as they are now.  We'd be taking time that previously we'd
be able to spend introducing new features and instead pushing the time into
stabilizing the release.  Upstream tracking may or may not continue in
rawhide (seeing as we have no frozen rawhide *but* many maintainers are not
using rawhide to actively develop for the next Fedora until after the final
release of the current Fedora in development).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100812/9a2fa603/attachment.bin