On Thu, 25 Oct 2007 10:55:41 +0000 (UTC) Kevin Kofler <kevin kofler chello at> wrote: > I have one possible suggestion (at least for F9+, it's probably too > late for F8) for this problem (maybe worthy of its own thread? > Anyway, here it is): > * make updates-testing available early, e.g. as soon as builds for > the new release go to dist-f*-updates-candidate, This has a set of problems. A) signing packages. This can somewhat be mitigated by using a signing server (which work is developing on), however for a while I'm not going to feel comfortable hooking up some automated process to sign packages. B) potential for broken deps. As we see from rawhide, or even updates today, deps can and will break often. Doing a full proper depcheck of all release + updates + potential testing updates takes a good long time due to having to figure out the multilib set. This can be made better by stop pre-calculating multilib but that isn't here yet and may not be for a while. C) mirror churn. It's hard enough to keep mirrors updated when we only push a couple times a day. If we were to churn the repo on demand we'd likely never see up to date mirrors and mirrormanager would be constantly dropping mirrors from the list. > * if a direct push to stable was requested, but the stable updates > haven't been opened yet, make the updates go through testing anyway, > and automatically push them as 0-day stable updates unless they have > been unpushed or the move request revoked. (Alternatively, the stable > updates could be opened early too, but it just doesn't make sense to > me to declare updates "stable" before the release.) > * Of course, start doing regular test update pushes for the new > release as soon as updates-testing is opened. This is a bit more reasonable, and I actually planned to do an updates push (both final and testing) prior to F8 going live. This is to pre-populate the mirrors with update content and give folks who do network installs a chance to install directly to the 0day updates rather than waiting a day. I'm not sure if we want to force final updates into testing, nor how early to do this. If we do release too early, we get people testing the release /plus/ the updates and missing glaring issues that may be in the release itself. > > The advantages and drawbacks of this approach as I see them: > + 0-day updates would be able to get some testing. > + Rawhide users would be able to reliably get security updates even > during the freeze. (Right now, they only show up in Rawhide if tagged > f8-final.) Which every security update that has been requested for Fedora 8 has been tagged. We take these things seriously and tag them as soon as we can. Once we stop taking in builds for the release seems like a great time to open up the update repos. > - Less testing for the packages which show up in the frozen release > (because testers will be split between f*-final and f*-final + > updates-testing). -- Jesse Keating Fedora -- All my bits are free, are yours?
Description: PGP signature