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? It's hard to test a moving target. > > Would an 8[1] month cycle cause fewer slips per release? Fewer bugs? I'm not sure that an increased cycle would really help. One thing I am curious about is why, when slipping for an Alpha target, the whole schedule slips. Can't we just take a week out of the Beta cycle? The amount of testing time is roughly the same. The other general thing is to utilize http://repos.fedorapeople.org to get wider testing for new features before merging them. Perhaps we could have a 6mo release schedule but a 12mo feature schedule. Thus, I would propose features *now* for F15, get them conditionally accepted and work on them in repos.fp.org (or rawhide if that is not possible). Then, we fork F15 from F14+updates and only merge in features that have proven stable enough for wider testing. The only way to make schedules more predictable is to keep "trunk" from breaking as much as possible. Breakage should occur as much as possible in private repos. Just some thoughts, hope they're helpful. Nathaniel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
