[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Security Response Team / EOL



On Fri, Apr 28, 2006 at 07:46:56AM +0200, Thorsten Leemhuis wrote:
> When a Fedora Core release reaches Maintenance state (such as Fedora
> Core 3 reached when Fedora Core 5 Test 2 was released), the
> corresponding release of Fedora Extras will also enter a Maintenance
> state. In this state maintainers will be allowed to issue updates to
> existing packages, but Maintainers are strongly urged to only issue
> severe bugfix or security fixes. New software versions should be avoided
> except when necessary for resolving issues with the the current version.

Currently there are five releases in maintenance mode, aka managed by
fedora legacy. Maybe in the future this will decrease, but somehow
whenever legacy tries to kick out a release some people start crying
and it is kept. But let's assume 3-4 releases on the average in the
future.

For a package maintainer that covers a package that has lived in these
releases this means 3-4 additional versions/specifles of the software
to maintain, e.g. (hopfully only) one version for the current 2 active
FCs and in the worse case 3-4 further distinct specfiles to look out
for.

I guess the packager will wish that upcoming releases will fix severe
bugs or security flaws to allow him to sync all his trees ;)

To cut a long story short: I would soften the above requirement and
make it a recommendation or similar.

And I would also include the legacy folks in this discussion (Cc'd),
as all of this very much depends on the EOL/concurrent releases
policies there. Some (unfinished?) thoughts about extras in legacy
have already been discussed in the past, and the outcome may prove
valuable.

I also think that the organisational separation of core vs extras
blurs in legacy mode, as legacy for core is already in a community
driven entity like extras is, so convergence is easier in that
domain. legacy is a community security response team for core and
creating a second for extras doesn't sound right, it's better to
consolidate forces.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpxbERykRtvO.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]