On Thu, 2010-08-12 at 13:39 -0500, Mike McGrath wrote: > Would an 8[1] month cycle cause fewer slips per release? Fewer bugs? For me, one of the guiding principles for Fedora QA's work on tools and policies has been this: time, by itself, doesn't fix anything. Making the schedules longer isn't going to stop people trying to cram fixes/changes in at the last minute. Stronger policies about what's allowed after a "freeze" - or just longer freezes in general - might be more effective at stabilizing things post-freeze, so we don't slip so much. Developing better tools and processes to find bugs *before* deadlines is more appealing than longer freezes, at least to me - but either of those is a better idea than lengthening the release schedule. If we really want to do releases on time without compromising quality, I think we need to work on three things: 1) Get new code into rawhide, and testable, as soon as possible. - This means running rawhide though, and that's not always easy.. 2) Be more aggressive about deferring features which are incomplete. - This isn't such a huge penalty anymore, since it's getting a lot easier to keep a personal repo for your new changes. 3) Work on tools to speed up the bug lifecycle. - automated testing to catch regressions - better debugging tools / docs I mean, honestly - we started accepting rawhide/f14 builds six months ago. Surely some of this work could have been tested earlier, and the stuff that wasn't available to test earlier.. should maybe wait until next release? -w -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
