Security Response Team / EOL

[Axel Thimm]

On Sat, Apr 29, 2006 at 11:02:46AM -0400, Jesse Keating wrote:
> On Sat, 2006-04-29 at 10:52 +0200, Axel Thimm wrote:
> > 
> > How about a compromise? Externally (toward the users) the official
> > position is that there is no official support (*) anymore other than
> > security fixes, while packagers are still allowed to update legacied'
> > releases at their own discretion w/o having to go through loops? 
> 
> Because no matter what we "say" is policy, end users would continue to
> see random packages change in EOL releases, which is not a clear
> message.

Don't call them EOL, they're in legacy/maintenance mode ;)

The message to the users is that after mode switching to legacy the
support for package upgrades drops. That's different from the promise
of no packages upgrades ever.

> Come on guys, if you need a longer lifespan than what Fedora
> provides (the full thing, including Legacy), mayhap you need to be
> looking for a different project.  RHEL/CentOS exists for a reason.

Noone is asking for longer lifespans, on the contrary, most of us (the
packagers) would be very happy if there were no or a minimal
maintenance lifetime only, so we won't have to fork the packages into
current vs mainentance modes. In fact the long total lifespan is what
generates this discussion.

I think we're arguing on the same side. We all want to look forward
with our packaging. And freezing upgrades on legacy releases will only
make packagers spend more time with old stuff (backporting security
fixes) that will then be missed with ongoing stuff. Even in the ideal
situation of 2 current and 2 legacy releases you end up maintaining 3
versions of a package. And right now we are still far from 2 legacy
releases (we're at 5).

It's a workload calculation, where you don't want to penalize
packagers, because you do want them to foxus on current/future
releases.

The next suggestion would be to completely take the load of the
forward looking packager and plac it on a security team. That will
also not really help, after all, the package maintainer is the one
that knows about his package the best and will need the smallest
amount of time to fix it (or upgrade it). So if you put all available
manhours together (packagers and security team) you will find that
most of the time it will be cheaper to have the package maintainer fix
the packages.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060429/ccfabef9/attachment.sig>