Exaggeration

Posted Sep 22, 2010 21:50 UTC (Wed) by dbruce (guest, #57948)
In reply to: A constantly usable testing distribution for Debian by Cyberax
Parent article: A constantly usable testing distribution for Debian

"Debian Stable rapidly becomes woefully obsolete - it's usually about 3-4 years old."

http://en.wikipedia.org/wiki/Debian#Release_history

No, it has never been more than 3 years old. The only time it was ever over two years old was between July 2004 and June 2005 (due to the infamously-delayed Sarge release). Until 2002, Debian released a stable distro every year. Since Sarge, it has been just under two years between releases.

So in recent years, Stable has always been between zero and two years old, with the mean age being about a year.

DSB

Exaggeration

Posted Sep 22, 2010 22:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

"No, it has never been more than 3 years old."

You're forgetting the time spent in pre-release freeze. For example, Lenny has Linux 2.6.26 which was released on 13 Jul 2008. So it's already 2 years old and is going to be about 3 years when Squeeze is going to be released.

Python 2.5.2 (in Lenny) was released on Feb 18 2008 - already more than 2.5 year old.

Exaggeration

Posted Sep 23, 2010 12:42 UTC (Thu) by dbruce (guest, #57948) [Link]

Good points - the stabilization process seems to add an awful lot of time.

DSB

Exaggeration

Posted Oct 5, 2010 13:19 UTC (Tue) by dererk (guest, #67491) [Link]

You are mixing a lot of real facts, but using them as your own purpose.

That is, following your understanding, Red Hat Enterprise Linux offers a 4 years old distribution (because they distribute 2.6.18 kernel which was realized 14th Oct 2006), or, in the same way, it's 6 years old, because it includes python 2.4 released on 2004...

It's a stable software, in software engineer that would basically mean it has been proven to work in most testing scenarios, unfortunately for some cases, *that time* is too much.

I really think CUT would be a solution for them. Once again, thanks JoeyHess the great tools you invent and code (altogether with etckeeper, debconf itself, and so on!)!

Exaggeration

Posted Sep 22, 2010 22:20 UTC (Wed) by foom (subscriber, #14868) [Link] (4 responses)

Well, it depends on how you count. For example, Debian Squeeze is not yet released. But it's going to be way outdated at release time, if you take some specific high-profile examples:
- Python 2.6 (not 2.7, released Jul 3)
- Linux 2.6.32 (not 2.6.33-2.6.35, 2.6.33 released Feb 24)
- GCC 4.4 (not 4.5, released Apr 15)
- Firefox 3.5 (not 3.6, released Jan 21)
- Thunderbird 3.0 (not 3.1, released Jun 24)

So, by your measures, Squeeze is not yet 0 years old, but if you measure by firefox version included, it's already 8 months out of date and it hasn't even been released yet.

I don't have a major problem with that; I use Debian on all my machines -- stable (lenny) on most of them. And basically the only software I've upgraded on those is emacs23 and linux 2.6.32.

But it does seem somewhat of a shame that it takes so long to stabilize things and get a release ready after starting to freeze packages, that much of the software is 6+ months out of date at the day of release. Maybe CUT will help with that.

Exaggeration

Posted Sep 23, 2010 15:04 UTC (Thu) by juliank (guest, #45896) [Link] (2 responses)

> Well, it depends on how you count. For example, Debian Squeeze is not yet
> released. But it's going to be way outdated at release time, if you take
> some specific high-profile examples:
> - Python 2.6 (not 2.7, released Jul 3)
Same for Ubuntu 10.04 and Ubuntu 10.10.

> - Linux 2.6.32 (not 2.6.33-2.6.35, 2.6.33 released Feb 24)
Well, 2.6.32 will be maintained longer than 2.6.33, 2.6.34, or 2.6.35; and makes much more sense for a Debian release.

> - GCC 4.4 (not 4.5, released Apr 15)
Same for Ubuntu 10.04 and Ubuntu 10.10; moving to a new GCC version is usually a bit complicated.

> - Firefox 3.5 (not 3.6, released Jan 21)
> - Thunderbird 3.0 (not 3.1, released Jun 24)
Mozilla stuff is generally a problem, as far as I know.

Exaggeration

Posted Sep 26, 2010 14:15 UTC (Sun) by pgquiles (guest, #70318) [Link] (1 responses)

>> - Python 2.6 (not 2.7, released Jul 3)
>Same for Ubuntu 10.04 and Ubuntu 10.10.

Ubuntu 10.10 already has Python 2.7

http://packages.ubuntu.com/search?keywords=python2.7

>> - GCC 4.4 (not 4.5, released Apr 15)
>Same for Ubuntu 10.04 and Ubuntu 10.10; moving to a new GCC version is >usually a bit complicated.

Ubuntu 10.10 already has gcc 4.5

http://packages.ubuntu.com/search?keywords=gcc-4.5

If Ubuntu can develop something quite stable with 6-month release cycles and 2-month stabilization cycles, why can't Debian try it? (openSuse has 9-month release cycle and also works well for them)

Exaggeration

Posted Sep 26, 2010 14:34 UTC (Sun) by juliank (guest, #45896) [Link]

> Ubuntu 10.10 already has Python 2.7
But it's not the default and not supported, so practically useless.

> Ubuntu 10.10 already has gcc 4.5
It's not the default, so it does not matter.

Debian has those packages as well, in experimental. In Ubuntu, there is no thing such as experimental, so it needs to be in maverick in order to be in Ubuntu.

Exaggeration

Posted Sep 30, 2010 17:49 UTC (Thu) by pboddie (guest, #50784) [Link]

But it's going to be way outdated at release time, if you take some specific high-profile examples:
- Python 2.6 (not 2.7, released Jul 3)

I suppose using something like Python 2.5 (as I do on the semi-supported Kubuntu 8.04 release) occasionally results in brushing up against code written needlessly against Python 2.6-or-later features, but quite a lot of that can be fixed quite quickly, especially if that code is limited to people doing stupid things with setuptools instead of just providing sane distutils stuff in their setup scripts.

Really, Python 2.6 is the launchpad release for people jumping to 3.x, with 2.7 being the successor in that regard, plus extra gravy.

Your other examples are somewhat better, however, although there's almost always a case to be made for holding back on the newer stuff, especially if adopting such stuff means several laps of the track for those having to integrate and test it with everything else.