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 thought Debbie and Ian were releasing patches on Tuesdays. Am I wrong?
Oh, wait, it is *that* company.
Nevermind.
Seriously, I wonder why the ridgid schedule. Wouldn't it be better just to release when things are "ready"?
The Kai's Semi-Updated Website Thingy
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.
First webpage of the day, and I read that as "Lesbian Decides to Abort Time-Based Frozen Embryos"
Linux distributions LOVE to come up with catchy names for their releases.
But sit down at a random machine and try work out WHAT release of Debian (or Fedora or whatever) you are actually sitting in front of and you can pull your hair out.
How is anyone supposed to remember that "Debian <insert-dumb-release-name-here>" is MORE recent that "Debian <insert-other-dumb-release-name>" ????
I suppose you are going to tell me to check /etc/issue
Oh THAT'S user friendly.
And what if /etc/issue has been emptied "for security reasons".
I can hear the support call already: "Er... Sir, if you can't work out what version of Linux you are running we recommend that you re-install, and also check the Wikipedia entry for Debian. .... Yes that's D-E-B-I-A-N"
I know as a maintainer that at one point "Sarge" was the most important word in your life, but for the USER (that's the person that is actually going to be using the OS you are working on), he doesn't know "Sarge" from "Etch" from "Horcrux".
AND HE DOESN'T CARE EITHER.
-paul
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!
1. Fixed freeze time
---
2. Change it to 3 years
3. Make in-between "small freezes" every six months or so
4. Rename "3 year freeze" to "LTS" to be not confused with "small freezes"
5. Move "smal freezes" to april and october
6. Rename the distribution to something more human, for example some asian, or maybe african word for community, sharing or generosity
7. Profit
I guess that puts an end to the phrase "when Debian freezes on a regular schedule"
...fills me with an absence...
Mind-blowing, man.
2 years just seems too soon for me. I would rather go for 3 year release cycle.
I really think you got it backwards regarding time based releases.
Your complaints really apply to _any_ sort of feature freeze, whether it's time based or feature based. Even if it is feature based, there will still be more incomplete features that someone wants to include. The only way to prevent a dev from being artificially constrained is to get rid of feature freezes altogether. But, no distro would be able to work with that.
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.
The point of time based releases is that they make it easier for distros and projects to synchronize. In this case, instead of upstream having to work with Debian's feature freeze and Ubuntu's feature freeze, they now only have to work with a single Debian/Ubuntu feature freeze. Having less feature freezes to worry about should free up the devs.
So, time based releases actually help, not hinder.
BTW, I recommend Mark Shuttleworth's blog. He has been talking about this issue, and he brings up allot of interesting points. Take care.
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!