Security Response Team / EOL

[Michael Schwendt]

On Fri, 28 Apr 2006 12:50:27 +0200, Thorsten Leemhuis wrote:

> Am Freitag, den 28.04.2006, 12:20 +0200 schrieb Patrice Dumas:
> 
> >  And for
> > the users it depends, some want updates other don't.[...]
> 
> 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
> people want new stuff they are probably installing new distribution
> versions in any case (not all, but most). That's why I prefer "normally
> no big updates" variant for those that prefer a stable distributions.

Exactly. Legacy distributions don't make these users happy at all, since,
for example, KDE remains at 3.4.2 compared with upstream. Users, who are
in search of fresh software, want the current or most recent release of
FC+FE. They upgrade.

> > > Branches for new packages in CVS are not created for Distributions
> > > that are in Maintenance state. FESCo can approve exceptions of this rule
> > > if there are good reasons for it. The official package maintainers are
> > 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.

Time spent on trying to keep legacy branches alive is missing in other
areas. I'd rather see Extras packagers track Rawhide and prepare for the
next release of FC, so we have something to offer at the time of release
of Test1. Version upgrades in old branches--especially those which are
done without careful testing (like closed-eyes copy-to-branch-and-build
updates)--increase the risk of resulting in regression, dead-end breakage
and increased maintenance requirements. Such as but not limited to
requiring further version upgrades in build requirements or in
dependencies maintained by other packages (with Epoch bump or package
withdrawal as a worst-case).

> > > urged to fix their packages also for Distributions that are in
> > > Maintenance state. They should work hand in hand with the "Security
> > > Response Team" in case they don't have access to older
> > > distros anymore to test their updates. 
> > What about co-maintainership, if a maintainer volunteers for maintaining
> > the old branches?
> 
> I left co-maintainership (and your proposal) out for now because it
> would have complicated things even more. 
> 
> But we should work on the details for "co-maintainership" soon.

Co-maintainership, yes. Entering another discussion which loops back and
forth without agreement, no. Please, for now leave out the hypothetical
human resources who wish to maintain their own packages for many branches
for an undeterminate period of time. So:

How about we first define and agree on what level of maintenance we try to
offer in Fedora Extras for current releases? These are things we must
agree on! What do we try to offer? Ultimate stability? Leading-edge?
Bleeding-edge? Version upgrade races with upstream? No goals at all? This
thread even has the term "security" in the subject line. So:

We do agree that current branches of FE shall be kept safe with security
updates and that a security response team shall intervene where package
maintainers cannot/do not react in time. Do we agree on that?

That would be one step away from the infamous dumping ground. If we agree
on how we try to maintain the current branch(es), we can proceed to
finding out what additional or different policies, procedures and
resources may be needed for legacy branches.

We do agree that package maintainers may abandon their packages for legacy
branches, don't we? A marker-file in CVS is easy to do, an unimportant
implementation detail. A security response team (or co-maintainers,
whatever, it doesn't matter) would need to take over those packages.
Thorsten's message even tried to address that issue and added June 15 2006
as a time limit for proof of activity of the security response team. If
packagers are permitted to add entirely new packages to legacy branches of
FE, this may increase the maintenance burden for the security rt, since
a) the packager cannot guarantee that he does the maintenance himself for an
undeterminate period of time, and b) neither can he be forced to do it.

> > What is the meaning of 'supported' for FE4 and FE5?
> 
> Good question. 

No. Read on.

> >  I consider that
> > FE is unsupported (as in the no waarranty clause of free software licences)
> > being a project based on volunteering.
> 

Silly. Look up the word "support" in a dictionary! The support we at
Fedora Extras offer [or try to offer with no guarantees] is the level of
maintenance: creation of packages, reviews, updates, upgrades, responses
to bug reports, bug fixes, communication with upstream developers,
monitoring of upstream activity wrt bugs, availability of servers and
repositories, availability of rebuilds for FC(n+1), [...]