[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian release cycle for enterprise ?

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


	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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: