Security Response Team / EOL
pertusus at free.fr
Fri Apr 28 11:43:46 UTC 2006
> > I don't think this constraint is productive. As Axel said keeping
> > spec files synced is simpler most of the time for the packager.
> The user IMHO is more important than the packager.
Maybe, but in a project based on voluntary work from packagers, putting
constraint on them is likely to decrease their reactivness, and in turn
it will harm the users. Otherwise said, if the "no updates" policy has
for consequence "Backporting is too much work, I won't bother for that
EOL FE branch, let the security SIG do the backport if they want to", it
is not a win for the user in my opinion.
> Doing both (e.g. 50% of the packagers update their packages to new
> versions, the other 50% only fix bugs) is IMHO the worst we can do. If
Why? Why couldn't it be acceptable that different packages have different
user base, different need for updates vs bugfixes (be it in FE current or
EOL), different risk of breaking stuff if updated versus security
fixes backported, different criticality, such that the risk of breaking stuff
by updating is offset by the time the packager loss by doing extra work
for EOL branches for some packages, and not for others?
> > I completly disagree with that. If a user don't want new packages that
> > entered extras while in maintainance state he shouldn't install new
> > packages. In my opinion the maintainer could be able to add new packages
> > for distributions in maintainance state, if he is confident that he
> > will maintain it. [...]
> I can live with that if others agree with it. But there were some people
> in FESCo that don't like this idea.
Why? The only reason that seems relevant to me is if it puts too much
pressure on the build sys, takes resources (disk space, badnwdth), or
requires somebody else than the maintainers work.
> I left co-maintainership (and your proposal) out for now because it
> would have complicated things even more.
Agreed. That's better if issues are not mixed, sorry for that.
> > What is the meaning of 'supported' for FE4 and FE5?
> Good question.
> > FE is unsupported (as in the no waarranty clause of free software licences)
> > being a project based on volunteering.
> Maybe -- but that's not a reason to leave known security bugs
> unfixed ;-)
Of course, but let's not mix that issue with the fedora extras EOL issue.
> I tend to "lets give the Security Response Team some (two? three?)
> months and revisit the EOL plans then again" ATM
I don't think the 2 issues of security team and FE EOL should be mixed.
More information about the fedora-extras-list