On Tue, 2007-06-26 at 03:49 +0200, Axel Thimm wrote: > On Mon, Jun 25, 2007 at 09:20:16PM -0400, Jesse Keating wrote: > > On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > > > That was one of the three options ;) > > > > > > I think a security-updates would not be bad, but maybe not in this > > > cycle, there's lot to do in short time and having a Fedora > > > enterprise-like stable branch with security updates isn't Fedora's > > > typical usage scenario. > > > > It's a tough thing to provide, and it would require anybody building a > > security update to build in two collections, potentially having multiple > > branches per release, one for "head" and one for "security", etc.. I think > > it's totally outside the scope of the Fedora project. > > I don't think it would require to build twice or open up several > branches, though, once against release & other security updates would > be enough. > > This assumes of course that FX at the end of its life is still > (mostly) *backwards* (!) compatible to FX at release time. Fedora's > pace and release cycle are balanced to not allow this to happen. For > example for F7 we even dropped mass-rebuilds, because we assumed that > not only FC6+updates is compatible to FC6 w/o, but even to F7. > > While dropping mass-rebuilds was a mistake, this at least demonstrates > that the Fedora model is not supposed to become backwards incompatble > with itself within a release. > > So the implementaion would be just another tag in koji. The maintainer > would have to fire a `make build-security' to have koji shove the > build into the proper tag which would inherit only release and not > updates. updates-candiates etc. would inherit from security. In fact > it looks like koji's model has already been planned to allow for this :) So, what happens when I have a package which I've previously updated and now need to do a security update for. The security problem applies to the original release. Either I have to a) Build twice b) Just push the newer security+otherstuffupdate. Which may depend on other non-security things. *This* is why the security plugin makes sense. Although it doesn't guarantee that you only get security changes, it lets you get just security changes + anything they depend on. At basically no cost to maintainers, testing, etc Jeremy -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
