[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Development to Official
- From: Kevin Kofler <kevin kofler chello at>
- To: fedora-devel-list redhat com
- Subject: Re: Development to Official
- Date: Thu, 25 Oct 2007 12:50:30 +0000 (UTC)
Jesse Keating <jkeating <at> redhat.com> writes:
> > * 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.
My idea wasn't to handle updates-testing like Rawhide, but like updates-testing
for a release.
> 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.
Right, that's the main drawback.
> 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.
There are 4 security updates in the pending updates queue for F8, for example
seamonkey-1.1.5-2.fc8 is sitting there (requested as a stable update, not
tagged f8-final). The others are: python-2.5.1-13.fc8 (requested: stable),
tar-1.17-4.fc8 (requested: stable) and openvrml-0.16.6-5.fc8 (requested:
testing). So there might be some miscommunication there (maintainers not asking
for f8-final tagging for security updates).
Kevin Kofler
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]