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