Re: Debian decides to adopt time-based release freezes
- To: email@example.com
- Subject: Re: Debian decides to adopt time-based release freezes
- From: Anthony Towns <firstname.lastname@example.org>
- Date: Mon, 3 Aug 2009 15:55:16 +0000
- Message-id: <[🔎] 20090803155516.GA16071@master.debian.org>
- In-reply-to: <20090730151756.GA14451@lisa.credativ.lan>
- References: <20090729010802.GA29421@melusine.alphascorpii.net> <20090730064541.GE29901@foghorn.stateful.de> <20090730071626.GC2911@torres.zugschlus.de> <20090730083746.GA11171@rivendell> <20090730090758.GE2911@torres.zugschlus.de> <20090730094948.GA27710@dario.dodds.net> <20090730130739.GB745@master.debian.org> <20090730151756.GA14451@lisa.credativ.lan>
On Thu, Jul 30, 2009 at 05:17:57PM +0200, Patrick Schoenfeld wrote:
> On Thu, Jul 30, 2009 at 01:07:39PM +0000, Anthony Towns wrote:
> > [...] The tradeoffs to me seem to be:
> > Debian stable Ubuntu LTS
> > 2 year rel cycle 2 year rel cycle
> > 3 years security 3 years desktop security, 5 years server
> > guaranteed freeze date guaranteed release date
> > support for all pkgs support for main, best-effort for universe
> > stabilise from testing upgrade support from previous Ubuntu 6mo release
> > upgrade from oldstable upgrade support from previous Ubuntu LTS (?)
> > support for 6-12 archs support for 2-3 architectures
> > availability of pre-installed systems
> > full-time security support staff
> > commercial quality support
> > larger userbase
> > some additional packages
> What do you intend to visualize with this comparison? After all
> its not really fair, to list a clear pro on the one side
> as a pro on the other side.
They aren't pros/cons, just the significant (technical) differences I
can think of.
> Your comparison fails this at least in architectures (2-3 is worse than
Supporting 2-3 architectures could be considered better by some people:
it's less complex, and allows for quicker changes -- there's no need
to wait for slow buildds, worry about obscure toolchain errors across
as many architectures, or deal with differences like the kfreebsd/hurd
people face now and then.
There's plenty of reasons why 6-12 architectures is a "better" choice,
but it's not better in all possible ways for all possible use scenarios;
it's a tradeoff.
> Its not "at least as good as Debian" as appearently merges does not
> happen automatically.
Given the freeze-timeline proposed it could/should be. Ubuntu has its
"DebianImportFreeze" for karmic scheduled for June 25th; which should
translate for an LTS import freeze on December 25th-ish, shortly after
the Debian freeze begins. At that point, the vast majority of universe
packages in Ubuntu LTS should exactly match the Debian version, and
Debian will disallow uploads that don't fix RC bugs, which should allow
Ubuntu to remain synced with very little review, until Debian releases, at
which point security updates issued by Debian should also apply to Ubuntu.
The way things currently work, unless Debian's already in freeze when
Ubuntu stops importing, there'll be lots of updates in testing/unstable
in the four or so months before Ubuntu starts offering security support;
and when Debian does release it'll be offering security support for
later versions of most things. Going back in time, there's been three
Debian freezes since Ubuntu started:
sarge: 2005/05 - 2005/06 (after dapper's import freeze, well before edgy's)
etch: 2006/12 - 2007/04 (decent hit for feisty's import freeze)
lenny: 2008/07 - 2009/02 (decent hit for jaunty's import freeze)
dapper and hardy are the two Ubuntu LTS releases so far, dapper reached
its desktop end-of-life a couple of weeks ago. feisty hit its end-of-life
in October last year. I'm just extrapolating from karmic's release
schedule; I haven't checked the schedules weren't different historically.
Based on that, comparing universe packages in etch-vs-feisty and
lenny-vs-jaunty for version differences, and any differences in security
updates could be interesting, actually.