Hello Release Team. For next release cycle, I have a simple suggestion to improve the release process: Don't release software with major bugs in it. It might make sense for the next release cycle to have a longer hard code freeze (2, maybe even 3 weeks) during which developers are encouraged to work on bugs on the blocker list. The 'encouragement' would come in the following form: if there is a non-zero number of bugs on the blocker list then GNOME does not release. I think under this kind of pressure the few bugs that are on the blocker list every cycle would have the attention of the entire project focused on them and would be fixed quite rapidly. So although it might result in delays in the release (every six months is nice but does it have to be *exactly* six months?) the delay probably would not be very long. The delay is merely following the natural definition of "blocker". I think we're so caught up in releasing every six months that we've developed the mentality that we dare not deviate from the schedule at all (even in the presence of blocker bugs). This hurts our users who are given "stable" versions of GNOME which are known to contain major bugs. When you can go on Bugzilla right now and see "Blocker bugs: GNOME 2.12.x (these must be fixed before/in the specified GNOME version)" with a list of open bugs under it something is wrong. The primary benefits of a regular release schedule are not compromised by taking an extra week or two if necessary to make sure we're not releasing software with major bugs and I don't think this is a slippery precedent. I understand that this might have an effect on Ubuntu (and possibly some others). Ubuntu, however, has a grace period of about a month and usually ships the .1 release anyway. I don't imagine that delays of a full month would occur. In the event that there is a bug that is a deep-rooted issue that everyone agrees can not be fixed without devoting a serious amount of time then the release team would, of course, reserve the right to release anyway. Even if the pathological case where for some reason the release didn't occur within a month, Ubuntu would still be able to ship a -very- stable pre-release version which has now been hard code frozen for more than a month (and is certainly of no lower quality than if we had done the release with none of the blockers fixed at all). Thanks for your consideration on this issue. Cheers :)
Attachment:
signature.asc
Description: This is a digitally signed message part