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@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
