On Wed, 14 Nov 2007 22:58:27 +0100 Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > You received feedback from some people, including from Hans, Me and > some others. On "# Date: Fri, 26 Oct 2007 13:52:34 -0400" you in > https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02295.html The crux of Hans' complaint as I understand it is that there is an actual freeze, at all. That there would ever be a time where a build done doesn't automatically go into a release. And I'm sorry, but I just can't possibly imagine doing any kind of release with any sort of quality if there wasn't some sort of freeze. I fought with QA for the shortest freezes possible for a reasonable release cycle, and that's what we have in the proposed changes/schedules. Your QA team would like even longer freezes. I'd like you to find any other distribution that doesn't do some sort of a freeze for a release. And I took a lot of your input and incorporated it into the proposal, like weekly snapshots, and discussion of at some point being able to compose two trees, the pre-release tree and the next rawhide each night. Likely can't do that for F9, but looking into the future. Then it digressed into arguing about freeze times, and while I appreciate your opinions, I also have to rely upon my experience of actually doing the releases and knowing how much time we need with limited tree changes. I think there is one clarification that needs to be made, you at one point asked: F9 hypothetical schedule: Final Development freeze is 20080408 -- thus all updates after that point that are *not* release-critical gets tagged as "updates candidate" afaics (at least that's how I understand it from the description; please tell me if I got something wrong). Thus non-critical stuff doesn't make it into the tree for 23 days (release is scheduled for 20080501). I should note that during that time we're taking more things in that just 'release-critical' updates. We're taking (with review) reasonable bugfixes. It's the opportunity for all the groups to look at what we're proposing as the final package set and look for bugs that should be fixed. Once we create the first Release Candidate, that's the point when we're only taking in release critical fixes. I should note that even /with/ our review, a few builds slipped in that broke things pretty badly for the release. A late rhgb build caused a lot of boot hangs. A late selinux-policy build broke selinux. The rhpxl build we did late to fix graphical boot broke ps3. There were a few more too. These are all examples why not having review and not being very critical about every change going into a release can have very nasty results. I'd be more than happy to continue discussing why the proposal is the way it is. We didn't just pull numbers out of our butts because we felt like it, there are very real reasons and experiences that have led us to want a slow down to changes being introduced to the tree, along with a reasonable enough amount of time to actually create release candidate trees and validate them before throwing them at the mirrors, and giving the mirrors enough time to sync up for the release. Your QA team wants enough time to sufficiently test the proposed bits for release without adding new builds to the mix and invalidating tests. My entire motivation has been to find ways to accomplish the slow down for the release tree while providing outlets for builds to continue (and even be tested!). -- Jesse Keating Fedora -- All my bits are free, are yours?
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
