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;
