Mike McGrath said the following on 08/16/2010 12:18 PM Pacific Time: > 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 It is implicit here: https://fedoraproject.org/wiki/Releases/14/Schedule It is more explicit here: http://poelstra.fedorapeople.org/schedules/f-14/f-14-devel-tasks.html -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
