Development to Official

[Jesse Keating]

On Thu, 25 Oct 2007 10:55:41 +0000 (UTC)
Kevin Kofler <kevin.kofler at 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071025/62f379f4/attachment.sig>