Plan for Today's (20070625) Release Engineering meeting

[Jeremy Katz]

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