Slashdot Mirror
Debian Decides To Adopt Time-Based Release Freezes
frenchbedroom writes "The ongoing Debconf 9 meeting in Cáceres, Spain has brought a significant change to Debian's project management. The Debian project will now freeze development in December of every odd year, which means we can expect a new Debian release in the spring of every even year, starting with 'Squeeze' in 2010. Until now, development freezing was decided by the Debian release team. From the announcement: 'The project chose December as a suitable freeze date since spring releases proved successful for the releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux 5.0 ("Lenny"). Time-based freezes will allow the Debian Project to blend the predictability of time based releases with its well established policy of feature based releases. The new freeze policy will provide better predictability of releases for users of the Debian distribution, and also allow Debian developers to do better long-term planning. A two-year release cycle will give more time for disruptive changes, reducing inconveniences caused for users. Having predictable freezes should also reduce overall freeze time.' We previously discussed talks between Canonical and the Debian release team about fixed freeze dates."
Two things to note.
First, the small font used for the non-mainpage stories makes me read the story title as "Lesbian decides to adopt time-based release freezes".
Second, limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process. While it might be useful to encourage faster development in some cases, it is just as likely to force a new feature to be dropped at the last minute if it can't make it through the door in time.
I'd rather they stick with feature-based releases which focus on the quality of features rather than trying to force feature development into a specific duration.
I've always liked Debian's way of doing their releases, it was unique and worked really well for them for awhile; I hope this new way works out for the best and mutually benefits both Debian and Ubuntu.
Still thank you to the debian team for we depend on their hard work.
Wouldn't it be better just to release when things are "ready"?
Would you want to delay an entire OS due to the newest associated IM not being ready? In other words if you're hungry now, would you care for the larger part of the cookie now or would you rather stay hungry and wait for the whole cookie?
I am the lawn!
cat /etc/issue /etc/apt/sources.list /etc/lsb_release
cat
cat
Often works. It's by no means ubiquitous, I'm well aware, but it's rarely *that* difficult.
This is one of the reasons I like Slackware.... tiny things like this ARE considered:
cat /etc/slackware-version :-)
Ubuntu does reasonably well with this. They get the catchy name *and* obvious order by coming up with names associated with a letter, in alphabetical order. Jaunty is more recent then Feisty because "J" comes after "F".
And then they also stick the month and year on as the version number, which I thought was a good idea. 9.04 Jaunty is more recent then 7.04 Feisty because "J" comes after "F" and "April 2009" comes after "April 2007".
And finally you get an "about" page that lists both the name and the number.
Does a line appended to your comment give your post meaning in and of itself, or only in relation to those without?
Oh for pity's sake.
Debian: cat /etc/debian_version /etc/redhat-release
Fedora: cat
It's not hard. It's easy. It's one command, for crying out loud. If you can't run one command you've no business using a computer.
Seeing as how debian only releases every century or so, that's not really a problem. The current release is the one you hear about. If it's not that it's the one you vaguely remember. The one before your kids were born, you were in high school, or possibly back when MTV played music videos (or insert some other thing waay back). If it's a version you haven't heard of it's so outdated that only the old long bearded unix sages locked up in corporate server farms programing cobol/fortran remember much about.
Slackware is hardly alone in this:
/etc/debian_version
/etc/lsb-release
/etc/redhat-release
Debian:
/etc$ cat
5.0.1
Ubuntu:
~$ cat
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"
Redhat/Oracle [I assume Fedora/CentOS too?]:
~]$ cat
Enterprise Linux Enterprise Linux Server release 5.2 (Carthage)
Nothing to see here
For the record, in Debian this can also be found in /etc/debian_version as well.
I run Debian stable on my laptop, and I don't see why I would run Ubuntu instead of Debian. Debian has a larger range of packages and is much more flexible and forgiving if you don't want to run one of the preconfigured subdistros (i.e. Ubuntu/Gnome, Kubuntu, Xubuntu etc.). Plus, having run distributions like Debian/sid or Gentoo, which have continuous updates, I find the reliability you get from a computer which never randomly changes packages is a plus. The six-monthly timetable of Ubuntu is much too short for that; I would've got the bugs ironed out just in time for a new release. There is, as you indicate, the LTS releases: but they're just one of the regular releases and this means you get people pulling in opposite directions (latest and greatest vs good for the whole three/five years). Also, is there some guarantee that you can always upgrade from one LTS release to the next LTS release?
In short, with Debian stable, I know what I'm getting. With Ubuntu, in my mind there's too much uncertainty that I'll have a reliable computer for its lifespan. Even if there isn't any uncertainty, there's no reason to convert. No matter how good Ubuntu is, I can't imagine it being better enough than Debian (on my desktop for my purposes) to warrant converting.
(That said, I would like answers to my questions. Googling "Ubuntu LTS" gives you almost nothing about LTS in general. The one page that's not information about a specific release has almost no content: a paragraph about Ubuntu's normal release schedule, a paragraph about the LTS release schedule, and a paragraph taking you to a list of pages about the beta releases (!) of distributions released a year (!!) or three (!!!) ago. This absence of information, and absence of relevant information, fills me with an absence of confidence, and it's one reason I'm not going to switch my laptop from Debian stable.)
Look out!
Debian releases also have version numbers.
For example, the current stable is Debian 5.0 (codenamed "lenny")... well, actually it's 5.0.2, but the .2 only matters if you're downloading disc images, as the updates are handled through apt.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
For Debian based systems:
/etc/debian_version
cat
You should probably get your centuries looked at, if you're only getting around two years out of them. Mine last a hundred years or so; I gather that's about average.
Look out!
lsb_release -a
I guess that puts an end to the phrase "when Debian freezes on a regular schedule"
(Ooh, I got an off topic mod for an on-topic question. Love it!)
I wouldn't delay the OS. I was referring to more the other direction. You would want to release when it is ready, even if that is prior to the scheduled date.
I - in a way - use Debian since I've switched from openSUSE to Ubuntu, so I'd be curious if Ubuntu would be affected.
The Kai's Semi-Updated Website Thingy
The debian page itself lists releases by number and code name. So does Mac OS X, of course they are all referred to by code name too, leopard, tiger, etc. The Windows world has it easy, Windows 7 comes after windows 95, as per standard numbering schemes. Don't forget that in number based versioning schemes 2.1 is different than 2.10, and that 2.1 is before 2.9, which in turn is before 2.10. In debian of course you could just replace codenames with stable, testing and unstable and be done with it.
To live till you die is to live long enough. -Lao Tzu, Tao Te Ching
Debian Unstable never has a version number. Ever. It also never 'releases' - things trickle into Testing after so much bug-free life in Unstable. It is Testing which eventually becomes a release and has a version number.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
...fills me with an absence...
Mind-blowing, man.
You would want to release when it is ready, even if that is prior to the scheduled date.
Within most FOSS projects "ready" is a very relative term. Most of us have probably used a lot of good functioning software before it was ready. Take Firefox 3.5 BETA for example. It worked close to as good as 3.0 in terms of stability. The problem with your reasoning is that you treat the project as a whole, which is fine, but never forget that these packages often have independent devs whom don't really care about your cycle at all times. So even if application X will be ready in time, the devs for application X will instantly work on next version, unless you choose the less featured stable. Ubuntu solves this partially by releasing normal and LTS releases.
I am the lawn!
jrodman@calufrax:~> cat /etc/debian_version
squeeze/sid
Oh that's obvious.
-josh
user@marvin:~$ cat /etc/debian_version
4.0
Shouldn't be running sid if you don't know what sid is.
No idea at all I'm afraid; it's not something I've ever wondered about. I guess you could manually compile a kernel, but I expect there'd be a bunch of userspace apps you'll also need to installl like an ext4 version of fsck.
Look out!
For Arch: it's Arch. :)
have you read the Moderation Guidelines Addendum?
Dude, this is a REAL problem not some piece of theory you can stir in your brain and decide if its "true" or not:
Look, there are several major Linux distributions all with weird release names, and
there is categorically no resource on the Internet that lists all the release names, what
OS they correspond with and what release number.
At least with FreeBSD it calls itself "FreeBSD X.Y" so you know -
a) which distribution it is (i.e. you know its not OpenBSD NetBSD BSDi or some Linux-based thing)
b) which version of the distribution it is.
Any person using Linux over a long period in time who is NOT interested in the operating system per se gets totally confused and annoyed because all these release names are just one big blur.
-paul
salix:~% cat /etc/debian_version /etc/debian_version
5.0.2
salix:~% ssh tuva cat
4.0
It's telling you you're not running a real release at all, but testing or unstable, or whatever it's called (I almost never run anything but stable). Perhaps that file should be clearer ... but if you need that, you probably shouldn't
be running anything but a stable Debian release.
"The better way to look at it is to look at what a distro gives to the upstream: bug reports and feedback. If different distros featurefreeze on different versions, then upstream is getting said feedback from multiple distros regarding multiple old versions. Obviously, the more different old versions that people are using, the more confusing and less useful this feedback will be."
I'd say that's because most upstreamers don't give proper engineering a damn. Since they usually only deal with their own little portion of the software landscape they usually don't pay attention to those "little" issues as segregating delivering bugfixes from new features, feature and bug regressions or simply making clear what they are going to support with regards of stable vs on-development versions.
Distributions, on the other hand, are all about integrating thousands or even tens of thousands of software packages so they simply can't go with "bleeding edge" if only because "bleeding edge" means different things to different software projects. I'd bet that if there's a solid commitment from software project foo about saying "version X.Y is our stable release and so it will be supported at least for X months/years" distributions would gladly use X.Y instead of X.Z on their stable launches; but since there's no "blessed versions" each and every distribution publishes "whatever is current now" which ends up with different distributions using different versions.
Even then, I don't see so many bugs against old versions being managed as they should be: they usually are not accepted or not analysed on the grounds of "use our bleeding edge version bar and see if the bug is still there". They forget that on one hand more obscure bugs will only show on special circumnstances and they are a treasure and on the other that even if it's an old release the bug is still there; they could have a case if they could say: yessir; your bug #12345 affects version 1.2.3 but it's corrected on 1.2.5; as you know, extraversion number means that exclusively bugs are corrected but functionality is unchanged so you can easily drop it out on your environment without worries. Maybe then distributions like Debian wouldn't be so hard on not upgrading programs within the same distribution versions and doing locally their backporting (and probably reinventing the wheel, and probably not by the best fitted individuals).
"Having less feature freezes to worry about should free up the devs."
That's a lost battle and upstreamers wouldn't need to worry about destribution freeze times *at all*: it's neither their bussiness nor anything they can control. What they can do is making the commitment of publishing a stable and supported version of their software and then distributions could use it on their products. It might happen that their glarining new version slips by days to the freeze date of distibution X but that won't worry neither the upstreamers (well, they'll use it on their next release) nor the distribution (am I choosing the "proper" version of this software or will it be a transtional one that will go unsupported in few months or even weeks?).
"I recommend Mark Shuttleworth's blog. He has been talking about this issue, and he brings up allot of interesting points."
I don't follow his blog but from time to time to give it a fast look but on my opinion, while not saying he has not some good ideas, they're not ideas I didn't read before anywhere else and they all seem just a bit too much as those end user "magic recipies" the like of "that many Linux distributions only spread efforts instead of concentrating them; there should be only one distribution". Well, which one then? "The one I happen to use, of course".