Security Response Team / EOL

[Patrice Dumas]

> 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

Of course time spent somewhere isn't available elsewhere, still it 
should be the packager choice.

> 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

Having maintained packages that work with devel should be a requirement, but
having packages added to legacy branches shouldn't be prevented.

> 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).

The packagers should be trust to do things right. Of course if the
packagers are forbidden to add a package for legacy branch they cannot do 
things wrong, but it is not the right way to promote quality.

> 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?

I think so.

> 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.

Right.

> 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.
 
Of course, but a packager that add new packages to legacy branches 
should guarantee that he (or a co-maintainer) is willing to do the 
maintainance, just like he guarantee that he is willing to maintain the
package in current branches.

Of course the will may change in the future, but what we can do in that case
doesn't seems to be different in the case of legacy than in the case of
supported packages/packages branches.

> 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), [...]

Ok, I guess I didn't express myself correctly. In any case I agree with
you, with 'try to offer with no guarantees', as there this is a voluntary
project.

--
Pat