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
Attachment:
pgptFcijouHm2.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
