The slip down memory lane

[Mike McGrath]

On Mon, 16 Aug 2010, Peter Jones wrote:

> On 08/16/2010 02:06 PM, Mike McGrath wrote:
> > On Mon, 16 Aug 2010, Peter Jones wrote:
> >
> >> On 08/12/2010 02:39 PM, Mike McGrath wrote:
> >>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> >>>
> >>>>>>>>> "BN" == Bill Nottingham <notting at redhat.com> writes:
> >>>>
> >>>> BN> I can't help but note that the slips have become more frequent as we
> >>>> BN> started to actually *have* release criteria to test against. We
> >>>> BN> didn't slip nearly as much when we weren't testing it.
> >>>>
> >>>> To me this implies that we should begin testing earlier (or, perhaps,
> >>>> never stop testing) and treat any new failure as an event of
> >>>> significance.  It's tough to meet a six month cycle if we spend half of
> >>>> it telling people to expect everything to be broken.
> >>>>
> >>>
> >>> Possibly also stop changing earlier?
> >>
> >> The window for changes is already far too short.
> >>
> >
> > How long is that window anyway?
>
> Depends on how you count.  If we count development start to feature freeze:
>
> F12: 48 days (including july 4th)
> F13: 53 days (including christmas and the US thanksgiving holiday)
> F14: 63 days (including july 4th)
>
> Or maybe development start to alpha freeze:
>
> F12: 76 days (including july 4th)
> F13: 84 days (including christmas and the US thanksgiving holiday)
> F14: 70 days (including july 4th)
>
> Of course, some people would like to count from the previous "Final Development
> Freeze" (or even earlier) to, say, feature freeze, even though this is wildly
> unrealistic for many of us:
>
> F12: 105 days (including july 4th)
> F13: 133 days (including christmas and the US thanksgiving holiday)
> F14: 115 days (including july 4th)
>
> this basically assumes nobody has to do any work on the previous release after
> the final development freeze, which isn't really true.
>
> (I realize there are other important holidays in other countries, but I figure
> this is a reasonable enough sample for exemplary purposes)
>
> Actually, from computing these numbers I think the best lesson is that our
> schedules have been so completely volatile that it's very difficult to claim
> they support any reasonable conclusions.
>

I think this is worth further discussion.  If the number is towards the
48-63 days level and that's what window people are actually doing
development that may be a problem because it is an extremely short time
period.

It's also interesting that with all the freezes, deadlines, etc we have
firm explicit set dates.  While active development is implicit.  it might
be worth it to set active deployment as an explicit time period just as
another reminder to everyone about when major changes are going on vs when
they aren't.

	-Mike