Proposal: security-patch team for hamm
Hi all,
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).
The motivation for this suggestion comes from a debate on comp.os.linux.misc
(thread subject: "Debian advocates") in which it was pointed out that for
whatever reason some don't (read: can't) upgrade their boxes immediately every
time a new stable release comes out, and it would be extremely useful to have
security patches for awhile at least. The number of security fixes per month
isn't all that large, and here's the kicker: when challenged that this would
require SPI paying people to do it (b/c the developers proper have of course
upgraded already), I countered with the idea that there are many of us out
there who aren't developers but would love to contribute in a way like this.
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.)
I'll happily lend some of my time and "secondary system" 486 to the effort.
waitin' for the deluge,
jg
p.s. but don't count on me to be the organisatrix. Er, or the organiser. (-:
Reply to: