On Fri, Jun 08, 2007 at 09:41:09AM +0200, Fr??d??ric PICA wrote: > This the follow up of the same thread in debian-release : > http://lists.debian.org/debian-release/2007/06/msg00039.html In that thread, Martin Krafft wrote: ] To support a release for 4-5 years, we would need substantially more ] resources: people who backport security fixes and maintain the ] archive, mirror operators who don't mind additional gigabytes, ] package maintainers who don't mind cooperating on old packages, and ] upstreams who are equally cooperative. There's a lot of value to being able to update regularly and take advantage of new developments, whether you do that at a twice-daily interval (testing, unstable), three monthly interval (ubuntu), which is an important consideration in regards to regular releases and minimising freeze times and so forth. I'm going to ignore it completely for the rest of this mail though. One thing I think's interesting is comparing the lifetime of systems like Windows 98 or Windows XP to Debian -- ie, considering people still running hamm today, or still doing installs of potato or woody, and what it would take to support that sort of usage. I think there's probably a few factors to take into acocunt here: i = initial time to review the upgrade and be confident it will work d = planning and downtime to actually do an upgrade l = preferred lifetime of installations For "i", it's probably fair to say that major Windows upgrade tend to have a longer burn in period due to people preferring to wait for bugs to be worked out and service packs to be released before considering major upgrades. For Debian, most of the bugs are worked out before the stable release (or at least, most of the bugs that are going to be fixed anyway), and it's easy to get experience with the new OS while it's in development. Likewise "d" is reduced for Debian systems because it is fairly easy to do an upgrade -- some configuration may need to be retested and updated, and some packages may need to be replaced instead of upgraded, but that work is relatively minor compared to reinstalling and reconfiguring a system from scratch. For "l", in Windows circles it's traditional to take that as the lifetime of the hardware, so three-to-five years; though in Debian circles you might often expect an installation to last through multiple changes of hardware, and thus be able to consider it independently. It's probably worth considering a variation of that, l' = preferred availability for new installations so that if l'=2 and l=3, you know you have a two year period when you don't need to worry about installing anything but XP, and you also know you're not going to be forced to upgrade any of those computers for three years -- which means two (l') years of commercial availability, and five (l+l') years of security support. If we define s = desired length of security support r = release cycle length and we calculate: t_release = date "release" is released a_release = date "release" is available to be installed e_release = date "release" ceases having security support as t_lenny = t_etch + r a_etch = t_etch + i e_etch = t_etch + s a_lenny <= a_etch + l' t_lenny <= t_etch + l' r <= l' e_etch >= a_etch + l' + l = t_etch + i + l' + l = t_lenny - (t_lenny - t_etch) + i + l' + l = t_lenny - r + i + l' + l = t_lenny + i + l + (l' - r) e_etch - t_lenny >= i + l + (l' - r) So "oldstable" security support (how long we do etch security support after lenny is released) needs to last for at least "i+l" (since l' >= r), and "i+l+l'-r" if you're not synchronising your upgrade cycle with Debian's release cycle (ie, l' > r). At the moment that's one year, so we can work backwards and estimate for Debian users, l'=r = 1.5 years (minimising l'-r) i+l = 1 year (oldstable security support) So the usable lifetime of a release (l'+l) is 2.5y-i, and the maximum amount of time you can guarantee a Debian release is usable is 1y (if you're required to install the day before a stable release comes out, you'll need to do an upgrade within a year). If we want to choose l', l and i rather than calculate them, then sample figures like: l' = 1y6m ; i = 0y (always install the newest release) l = 3y (only do new installs on new hardware) might be appropriate, in which case you get: e_etch - t_lenny >= i+l = 3y ie, you would need oldstable support to last three times as long as it currently does. Alternately, you might consider: l' = 3y ; l = 0 ; i = 0 (have a 3 year cycle of upgrades, where every machine gets upgraded, including ones that were just installed yesterday; all machines run the same version of Debian) in which case: e_etch - t_lenny >= i+l+(l'-r) = 3y - 1y6m = 1y6m which we could support with only a 50% increase in our stable release cycle. Another thing to note is that if you end up with e_etch - t_lenny > r then you expect to have another release after lenny before shutting down security support for etch, which means lenny+1 is stable, lenny is oldstable and etch is oldoldstable, and you're doing security support backports for three stable releases simultaneously. In general you're doing security support for: ceil((e_etch - t_lenny) / r) + 1 stable releases, which we can also calculate as: >= ceil( (i + l + l' - r) / r ) + 1 = ceil( (i + l + l' - r + r) / r ) = ceil( (i + l + l') / r ) If you're going to say i+l+l' = 5 years, and continue aiming for a 1y6m release cycle, that would mean maintaining security support for four (ceil(3.33)) releases simulatenously, rather than the current maximum of two. ] I am not saying your idea is bad, just that Debian can't do it. ] ] However, since you're not the only one with such interests, I could ] imagine a group forming to support e.g. etch for the next 4-5 ] years, backed by financial resources from the companies who are ] interested in this. If I were you, I'd find similarly minded people ] and pool resources. Which is to say "Debian doesn't do it", but I'm not seeing any reason why it can't be done as part of Debian if people are actually interested. The requirements would be: - having developers join the security team (possibly the unembargoed security team that currently maintains testing security updates) - maintaining additional suites in the security archive for suites older than oldstable - having a clear policy on what the additional security support means (is it limited to specific packages useful for "server" software eg, or the entire archive?) Those don't sound insurmountable to me. Moritz and Micah's talk on "Security Support In Debian" at debconf on the 19th is probably a good one for background on getting further on this if people are interested. I imagine video will be available online shortly after the event. Cheers, aj
Attachment:
signature.asc
Description: Digital signature