nerdyH writes "The Debian project's maintainer, Luke Claes, announced in an email Saturday that he will freeze the 'testing' or 'Lenny' tree, in preparation for a new stable release of Debian Linux in ... September! The freeze means that open source software developers have only a couple more days to package any applications that they want to be included in the next release of Debian — and by extension, in the inner sanctum source lists of distributions such as Ubuntu that are based on it. After the freeze starts next week, Debian maintainers will turn their attention to 364 release-critical bugs, and half-a-dozen high-priority goals. Given the work to be done, is September really feasible? Lenny always was a little slow getting back to his right place ..."
I run Debian in several capacities -- stable on my work server, and unstable on my personal machine.
A lot of people are going to (quite accurately, I guess) point out that for anybody running unstable/experimental there is not much to this. I mean, release numbers are soooo 1990's, as a simple apt-get update; apt-get upgrade brings you up to the latest packages. Even experimental seems to lag waaaay behind other bleeding edge distros though (gentoo).
Of course, the release is more important for new installs or people running stable. I have been very impressed with Debian stable, the SSH bug nonwithstanding.
As software packages and Linux get more mature, I see the definition of a "release" issue becoming even less important for the non-server / non-corporate user. Continuous upgrades are the way of the future. Even on the M$ side this seems to be true, with their MS office 200x and "automatic upgrades."
It matters in the sense that it's a way for Debian to release a new installer or move to a new standard for device management, but as a whole it doesn't *really* matter. If you are using "stable" in your sources.list verses the actually release name you'll in all likelihood just upgrade right along to the new release, and probably without much fuss.
I've never know invalid HTML to crash IE. I don't think I've ever know IE to take any notice of the code at all. From what I've seen, it downloads the page, strips the code, and then throws whatever is left at the screen...
I've never know invalid HTML to crash IE. I don't think I've ever know IE to take any notice of the code at all. From what I've seen, it downloads the page, strips the code, and then throws whatever is left at the screen...
Using stable in your sources.list is generally a bad idea. Moving from release to release should be a concious dessision done with a copy of the release notes in hand. Going in with a blind dist-upgrade often causes problems which may be tricky to recover from.
Etch is maintained to 2009-09. dist-upgrading a production server on release day, just for the fun of it, is probably a terrible idea. I'll be sticking with etch well into next year.
If you are using "stable" in your sources.list verses the actually release name you'll in all likelihood just upgrade right along to the new release, and probably without much fuss.
Never do this in any kind of production environment! You'd be crazy to do any release->release update without testing your own apps first.
I agree that the release idea is a little outdated (especially being a freebsd user myself), however it is nice especially with desktop distributions to get new releases. I gather from your post that you seem to have a pretty good grasp of linux so it is not as much an issue for you or me, but more for the common(?) user. For example in ubuntu most releases indicate a significant change in feature set or update in packages. Most home users are not running unstable, so in all likelihood most users are not going to see the latest and greatest in features (unless they have some distinct need and compile from source); the point being that it is a cause for excitement and something to look forward to, at least in my experience.
On a side note: congrats to you for using Debian unstable, I have had poor luck in the past:P
I used to use Unstable years back, but thought better of it when a nasty lilo bug rendered my hard drive non-bootable. This would have been in the period between 2.2 and 3.0.
You should give Sid another try. I've been running it on my laptop since Woody release and and I'm no where near the level of a developer. I run stable on all my servers but Sid is the only way to go for laptops. Etch is a lot better than Woody, but for personal machines, Sid is even better.
What the hell are you talking about? Using Sid is fine whether you're a Debian developer or not. I've used it for years on various machines and it's never bitten me. I do development in various languages and platforms, as well as need to compile C, C++ applications.
Your comment is typically elitest, and damnright wrong.
The problem with 'testing' is that it doesn't get security updates in a timely way. You have to do some gyrations to get the package out of unstable just that one time or else wait two weeks. That's how it was a few months ago anyway.
There's now a security repository for testing, just like there is for stable, and the repos are in a default sources.list if you install testing directly.
http://secure-testing-master.debian.net/ [debian.net]
As for me, of the machines I manage (my own and others in my family), the machines that cause the least troubles and have the happiest users are the ones running Debian Stable. I typically put Debian/testing (by codename) onto new computes as I acquire them, and once testing's become stable, I change them to stable. When I get a new computer, the old one goes to whoever wants it most.
The changes that happen to testing often bring nice new features with awful icky bugs that I don't really want to deal with,
No. I've tried several distributions with "rolling updates" but very often upgrades broke something on my machine. That is not a problem for me, but it WILL be a problem for Joe User.
Time-based releases two times a year are fine for most users.
I have to say the man has a point here. Rolling releases can be quite stable but every so often something will break and require you have a bit of knowledge about your system to fix it. Personally, I use Arch Linux and really enjoy using it, but I recommend other "stable" distros to people who want their computer to just work.
I am using testing at my servers and unstable/experimental on my desktops and laptops. Actually, in some cases, like TV servers are, I am using there unstable/experimental, too. At my old laptop, I installed unstable in late 2004 and ran that until February this year without any significant problem except that for some time I ran Firefox 3beta until it didn't become stable enough to go into Debian unstable (and became Iceweasel):)
A week or two ago, after one of apt-get update--apt-get upgrade iterations I'v
Just looked through the Debian package list. Looks like there's a lot I'd have expected that isn't there (ATLAS seems to be missing, as are the MUMPS and Fortran 95 programming languages - gfortran's f90 support is considered an old dialect, buggy and inadequate by a number of Fortran sites, and I didn't see Erlang on the list either). There are also a lot of ancient versions. For example, HDF5 1.6.6 has not been supported for some time. HDF 1.6.7 is the supported current version in the 1.6.x branch and has been since February, but the website makes it clear that the 1.8.x branch is intended as the official current release.
This is something that isn't Debian't fault -- there are way too many packages with way too many updates and far too few people helping -- and is something that all distributins suffer from. The specialist distros may help, but I don't like the concept. Beter to have a single core distro with extensions for specialist needs, as then you can combine extensions according to problem-space rather than dealing with the version hell that always happens when you mix distros.
Being confused is healthy. G95 (g95.sourceforge.net) is NOT gfortran, which is a Fortran 90 implementation, not a Fortran 95 implementation. gfortran is also listed by organizations such as NASA as not to be used due to severe bugs, with instructions to use g95 instead. Hey, I can only go by what they say. I can't access the other pages you linked to - I suspect they're now slashdotted. However, HDF5 1.8.1 is extremely stable and is the version people are supposed to be using. No idea what version of ATLAS
I've noticed that Debian, Mozilla, and Gentoo all have a nasty habit of saying, "that's not a bug!", and then when finally convinced:
"Well. We can't look at it for THIS release." And then your perfectly valid bug is shuffled off into a nice category where it won't upset their bug count for the release effort.
Note that the total number of bugs in Lenny is actually around 1800- only by a pretty fine comb have they been able to claim "only" 360 bugs.
There's a big difference between a release-critical bug (one that would basically ruin a whole release for everyone) and an annoyance (such as spewing diagnostic messages under certain circumstances on certain hardware).
Ubuntu has stuck to its schedules by releasing with plenty of release-critical bugs still in the air, and fixing most of them in post-release updates. That's cool for getting a release out there, but it basically makes every official release feel like an RC1.
an annoyance (such as spewing diagnostic messages under certain circumstances on certain hardware).
A system which spews diagnostic messages will fill up/var, and is far more than an "annoyance". If Debian Stable had such a bug, it would be inexcusable. People rely on it to run critical production systems.
How often do we complain about vendors shipping buggy software? And look at the graph for bugs for stable- in the last few months, it's skyrocketed!
Ubuntu has stuck to its schedules by releasing with plenty of release-critical bugs still in the air, and fixing most of them in post-release updates.
Yeah, I still shudder from the utter mess of Gutsy upgrades from Feisty. Not a single Ubuntu user in the office had a clean upgrade...
You're right, my example about diagnostic messages was a bad one. Nevertheless I've had dodgy hardware that produced regular messages on Linux and even BSDs, and while I didn't file a bug for it, I can see how somebody else would. Diagnostic messages are there for a reason, and it's usually your hardware's fault if they're flowing too thick.
The problem with local investigation of upgrade quality is that dumb ideas spread locally;)
I.e. one guy tells a friend about a package, and its upgrade is broken. Perhaps it was a third party package containing the old artwork and themes without setting up dpkg-diverts correctly. Or maybe one guy sets up everyone's computer in the office, and uses Automatix every time. It's hard for me to say who's fault it is or debug the past.
Ubuntu is built off a snapshot of Unstable, Not exactly, changes are auto-imported from debian unstable only for packages that don't have any ubuntu specific changes.
so I don't see how Debian's freeze will affect it. Debian tries to keep testing and unstable pretty close to each other. Changes in unstable that are not wanted in testing can be a major PITA when bugs need to be fixed (there is another way into testing but they prefer not to use it because the packages get far less testing when they are introduced by that route).
So while unstable is not technically frozen developers are strongly discouraged from uploading stuff to unstable that are not intended to become part of lenny
Packaging... meh. (Score:5, Insightful)
only a couple more days to package any applications that they want to be included in the next release of Debian
If you've left packaging until the freeze announcement, you don't deserve to be included.
Re:Packaging... meh. (Score:5, Funny)
Moderation -1
100% Overrated
Sorry. "Frosty piss".
Parent
Obligatory "does it matter?" (Score:5, Insightful)
I run Debian in several capacities -- stable on my work server, and unstable on my personal machine.
A lot of people are going to (quite accurately, I guess) point out that for anybody running unstable/experimental there is not much to this. I mean, release numbers are soooo 1990's, as a simple apt-get update; apt-get upgrade brings you up to the latest packages. Even experimental seems to lag waaaay behind other bleeding edge distros though (gentoo).
Of course, the release is more important for new installs or people running stable. I have been very impressed with Debian stable, the SSH bug nonwithstanding.
As software packages and Linux get more mature, I see the definition of a "release" issue becoming even less important for the non-server / non-corporate user. Continuous upgrades are the way of the future. Even on the M$ side this seems to be true, with their MS office 200x and "automatic upgrades."
Thoughts?
Re:Obligatory "does it matter?" (Score:4, Interesting)
It matters in the sense that it's a way for Debian to release a new installer or move to a new standard for device management, but as a whole it doesn't *really* matter. If you are using "stable" in your sources.list verses the actually release name you'll in all likelihood just upgrade right along to the new release, and probably without much fuss.
I'm excited either way because I 3 Debian!
Parent
Re:Obligatory "does it matter?" (Score:5, Funny)
I'm excited either way because I 3 Debian!
Well, I 4 Debian so I beat you.
Parent
Re:Obligatory "does it matter?" (Score:4, Funny)
Well, I 8 Debian and she loved it.
Parent
Re: (Score:3, Funny)
Threesome?
Re: (Score:2)
Re:Obligatory "does it matter?" (Score:5, Funny)
Parent
Re:Obligatory "does it matter?" (Score:4, Informative)
It has been known to happen! http://support.microsoft.com/kb/885932 [microsoft.com] http://support.microsoft.com/kb/811751 [microsoft.com] http://support.microsoft.com/kb/913788 [microsoft.com] http://support.microsoft.com/kb/909363 [microsoft.com]
Parent
Re:Obligatory "does it matter?" (Score:4, Informative)
Parent
Re:Obligatory "does it matter?" (Score:4, Informative)
Using stable in your sources.list is generally a bad idea. Moving from release to release should be a concious dessision done with a copy of the release notes in hand. Going in with a blind dist-upgrade often causes problems which may be tricky to recover from.
Parent
Re: (Score:3, Insightful)
Good advice.
Etch is maintained to 2009-09. dist-upgrading a production server on release day, just for the fun of it, is probably a terrible idea. I'll be sticking with etch well into next year.
Re: (Score:3, Insightful)
Never do this in any kind of production environment! You'd be crazy to do any release->release update without testing your own apps first.
Re:Obligatory "does it matter?" (Score:5, Interesting)
On a side note: congrats to you for using Debian unstable, I have had poor luck in the past
Parent
Re:Obligatory "does it matter?" (Score:5, Interesting)
I used to use Unstable years back, but thought better of it when a nasty lilo bug rendered my hard drive non-bootable. This would have been in the period between 2.2 and 3.0.
After that I switched to Testing.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
or better off using Gentoo.
I would, but I don't have a quad-core box yet.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Your comment is typically elitest, and damnright wrong.
Re: (Score:3, Insightful)
PS. You wimps who don't like living on the edge can always use 'testing'.
Re: (Score:2, Interesting)
The problem with 'testing' is that it doesn't get security updates in a timely way. You have to do some gyrations to get the package out of unstable just that one time or else wait two weeks. That's how it was a few months ago anyway.
Re:Obligatory "does it matter?" (Score:5, Informative)
Parent
Re: (Score:3, Interesting)
As for me, of the machines I manage (my own and others in my family), the machines that cause the least troubles and have the happiest users are the ones running Debian Stable. I typically put Debian/testing (by codename) onto new computes as I acquire them, and once testing's become stable, I change them to stable. When I get a new computer, the old one goes to whoever wants it most.
The changes that happen to testing often bring nice new features with awful icky bugs that I don't really want to deal with,
Re: (Score:2)
No. I've tried several distributions with "rolling updates" but very often upgrades broke something on my machine. That is not a problem for me, but it WILL be a problem for Joe User.
Time-based releases two times a year are fine for most users.
Re: (Score:3, Interesting)
Re: (Score:2)
I agree, but rolling releases are bloody fantastic for power users who can fix the little odd breakage.
Re: (Score:2, Insightful)
At my old laptop, I installed unstable in late 2004 and ran that until February this year without any significant problem except that for some time I ran Firefox 3beta until it didn't become stable enough to go into Debian unstable (and became Iceweasel)
A week or two ago, after one of apt-get update--apt-get upgrade iterations I'v
Lenny Brisco (Score:2, Funny)
Re: (Score:2)
but but it said they're going to Freeze Lenny!
cryogenically preserved he won't be able to do much...
Re: (Score:3, Funny)
Not Lenny!
Re: (Score:3, Funny)
Oh my god they killed Lenny. You Bastards!!!
If only... (Score:2)
Freeze just now? (Score:2)
Re:Freeze just now? (Score:4, Informative)
Parent
Re:Freeze just now? (Score:4, Insightful)
Just looked through the Debian package list. Looks like there's a lot I'd have expected that isn't there (ATLAS seems to be missing, as are the MUMPS and Fortran 95 programming languages - gfortran's f90 support is considered an old dialect, buggy and inadequate by a number of Fortran sites, and I didn't see Erlang on the list either). There are also a lot of ancient versions. For example, HDF5 1.6.6 has not been supported for some time. HDF 1.6.7 is the supported current version in the 1.6.x branch and has been since February, but the website makes it clear that the 1.8.x branch is intended as the official current release.
This is something that isn't Debian't fault -- there are way too many packages with way too many updates and far too few people helping -- and is something that all distributins suffer from. The specialist distros may help, but I don't like the concept. Beter to have a single core distro with extensions for specialist needs, as then you can combine extensions according to problem-space rather than dealing with the version hell that always happens when you mix distros.
Parent
Re: (Score:2)
You have confused me:
http://packages.debian.org/search?keywords=erlang [debian.org]
http://packages.debian.org/lenny/gfortran [debian.org]
http://packages.debian.org/lenny/atlas3-base [debian.org]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;dist=unstable;repeatmerged=1;src=hdf5 [debian.org] reports no bugs of any kind reported -- You should send bugmail requesting the new release of HDF5 if it really is stable.
(Mumps is missing, but I really wouldn't say I was missing it.)
Debian is renowned for its breadth of packaging; just how did y
Re: (Score:3, Informative)
What? (Score:2, Funny)
A new release already? That doesn't sound right.
This isn't the Debian I grew up with.
Something's fishy.
Re:What? (Score:5, Funny)
This is just a release announcement. As usual, they give you the month, but not the year.
Parent
Will they keep the bug count artificially low? (Score:5, Interesting)
"Well. We can't look at it for THIS release." And then your perfectly valid bug is shuffled off into a nice category where it won't upset their bug count for the release effort.
Note that the total number of bugs in Lenny is actually around 1800- only by a pretty fine comb have they been able to claim "only" 360 bugs.
Re:Will they keep the bug count artificially low? (Score:4, Insightful)
There's a big difference between a release-critical bug (one that would basically ruin a whole release for everyone) and an annoyance (such as spewing diagnostic messages under certain circumstances on certain hardware).
Ubuntu has stuck to its schedules by releasing with plenty of release-critical bugs still in the air, and fixing most of them in post-release updates. That's cool for getting a release out there, but it basically makes every official release feel like an RC1.
Parent
Re:Will they keep the bug count artificially low? (Score:4, Interesting)
an annoyance (such as spewing diagnostic messages under certain circumstances on certain hardware).
A system which spews diagnostic messages will fill up /var, and is far more than an "annoyance". If Debian Stable had such a bug, it would be inexcusable. People rely on it to run critical production systems.
How often do we complain about vendors shipping buggy software? And look at the graph for bugs for stable- in the last few months, it's skyrocketed!
Ubuntu has stuck to its schedules by releasing with plenty of release-critical bugs still in the air, and fixing most of them in post-release updates.
Yeah, I still shudder from the utter mess of Gutsy upgrades from Feisty. Not a single Ubuntu user in the office had a clean upgrade...
Parent
Re: (Score:2)
You're right, my example about diagnostic messages was a bad one. Nevertheless I've had dodgy hardware that produced regular messages on Linux and even BSDs, and while I didn't file a bug for it, I can see how somebody else would. Diagnostic messages are there for a reason, and it's usually your hardware's fault if they're flowing too thick.
Re: (Score:2)
The problem with local investigation of upgrade quality is that dumb ideas spread locally ;)
I.e. one guy tells a friend about a package, and its upgrade is broken. Perhaps it was a third party package containing the old artwork and themes without setting up dpkg-diverts correctly. Or maybe one guy sets up everyone's computer in the office, and uses Automatix every time. It's hard for me to say who's fault it is or debug the past.
Why the name "Lenny"? (Score:2, Funny)
Trump Ubuntu in their weird names, call it Lemmy instead.
You might at least get a good look at Debian from people other than us just on the name alone.
Re:Why the name "Lenny"? (Score:5, Informative)
Parent
Spinal Tap (Score:2)
September? (Score:3, Funny)
Great! Did they say what year?
Re:Ubuntu isn't based on Testing (Score:4, Informative)
Ubuntu is built off a snapshot of Unstable,
Not exactly, changes are auto-imported from debian unstable only for packages that don't have any ubuntu specific changes.
so I don't see how Debian's freeze will affect it.
Debian tries to keep testing and unstable pretty close to each other. Changes in unstable that are not wanted in testing can be a major PITA when bugs need to be fixed (there is another way into testing but they prefer not to use it because the packages get far less testing when they are introduced by that route).
So while unstable is not technically frozen developers are strongly discouraged from uploading stuff to unstable that are not intended to become part of lenny
Parent