Re: Proposal: security-patch team for hamm
Debian mail acct <debian@skyron.harvard.edu> writes:
> I've a proto-proposal to make: offering security updates for some or all
> earlier releases in the current "top-level" tree instead of just the current
> "stable" (i.e. for hamm as well as slink right now).
[...]
> So here's the idea: get a smallish set of volunteers who are still running
> earlier releases (i.e. hamm for now) and who are willing to test exploits &
> patches/fixes against it, and who will in turn roll the new .deb's when a hole
> pops up. Continue to do this until 3.0 comes out, and then drop support for
> all the 2.x's except the most recent one, and drop that when 3.1 is stable.
> Repeat for 3.x etc.
>
> Less-ambitious idea: always support the release prior to stable in this way.
> I really do think that otherwise, many potential debian users might be scared
> off by how closely it's assumed they'll track the current release tree.
> (Heck, Linus put out 2.0.37 almost 5 months after 2.2.0 first came out.)
That was probably Alan Cox, not Linus. A better example is how Sun is
still delivering Y2K fixes etc for SunOS 4.x.
The problem with these proposals is that (a) we don't even really
maintain stable all that well; trying to have the Debian group also
maintain hamm/bo/rex (even just security fixes) doesn't seem all
feasible just from experience; (b) the debian official archive, on
master.debian.org, doesn't even carry anything but stable/unstable
(and sometimes frozen), and the infrastructure (debian/changelog,
dupload, dinstall) doesn't support any distributions other than
stable/unstable/frozen.
Finally, there's nothing stopping interested folks from just creating
packages from security fixes stuff as it gets pushed into stable, for
instance.
I agree with you in principle, but lets try to solve the issues with
even just stable maintenance first. Motivated users providing
security fixes for prior releases are encouraged to do so. Heck, I'd
be happy to put links to sites with this stuff on
www.debian.org/releases/<whatever>.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: