Anthony Towns Elected New Debian Leader

daria42 writes "Australian developer Anthony Towns has just been elected Debian Project Leader starting 17 April. In his platform for election, Towns said the most important issue for Debian was 'increasing its tempo'. 'We've been slow in a lot of things, from releasing, to getting updates in, to processing applications from prospective developers, to fixing bugs, to making decisions on policy questions, and all sorts of other things,' he said."

Comments

Slowness

[CRCulver]

As the old saying goes, "Hell freezes faster than Debian Stable". Good to see that Towns intends to take action.

Re:Slowness

[Homology]

The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.

OpenBSD has a different release policy (i.e. a release every six months) that works very well. The 3.9 release is coming 1th of May, but the release in November will have version 4.0. Of course, someone had to ask if 4.0 will be stable. Theo de Raadt answered thus:

>Yep, the developers magically do more in the 6 months preceding 4.0
>than the 6 months preceding any other release. That's definately how
>it works.

We've been holding back about 50% of our work for each of the previous
4 releases, and now we are going to throw all those very large things
into what will become 4.0. It is going to be a fantastic catastrophy,
exactly like what all of you ".0 release" people expect.

Right... Get a grip.

Re:Slowness

[Homology]

So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.)

It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, while others are not fully supported due to lack of documentation/hardware/resources.

In general, if an arch is supported, it is supported well.

All the ports are there in source, and they may work for you, but really, who knows?

Ports are tested on all platforms, but some ports are not supported on some platforms either due to hardware limitations or bugs in the application.

A supported arch in Debian parlance, on the other hand, means that there is a working installer, you can coompile your own kernel on your own box..

OpenBSD has higher standards than just to be able to compile a kernel natively: Userland must also be built natively and it must be a useable OS.

... and virtually every debian package can be auto-built and available in binary form.

Now, this is silly. Of course OpenBSD offers pre-compiled ports (ie packages) for every arch where it makes sense. Obviously, on vax, for instance, there will be a limited supply of applications that may run on such a platform. However, there are quite a few packages available (not cross-compiled): ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/vax

Joke

[zaguar]

For those who were wondering, voting started in 2001. He was elected today because the commitee wanted to make sure the candidates were 'stable'.

Re:Joke

[wild_berry]

You forgot to mention that the candidates were also frozen for bugfixing. Towns has only lost two fingers to frostbite; the debian-privates e-mail list suggests that another candidate lost something more personal and delicate.

Re:Good Move

[babbling]

What makes you think that? I mean, sure, he stated that he wants to get releases out quicker, but that doesn't necessarily mean he will be able to. I imagine that has more to do with the independent, unpaid Debian developers rather than the project leader. It's rather likely that the previous Debian project leader also wanted a shorter release cycle.

This is one of the problems with free software. If developers are less accountable, fixed release dates are more difficult to achieve. On the other hand, almost all proprietary software seems to be facing the same problem, and sometimes to a greater degree...

Re:Debian

[lpcustom]

I have to disagree totally. Ubuntu does have newer software for it's main distro. Debian Testing has just as new software cept it works better. For example, Ubuntu is still using firefox 1.0.7. Debian testing is at 1.5. Ubuntu's latest dapper flights are basically Debian Testing with new artwork that says Ubuntu.
I like a ton of distros but I seem to always come back to Debian. For a bunch of guys that can't get their act together, they still make the others looks bad.

Best intentions...

[QuaintRealist]

I'd have to agree with you. One of the main reasons Debian has been slow to update has been the range of architectures and applications they attempt to simultaneously support. Other distros update faster, but most of them take one of two paths: a) limit supported architecture (usually to the x86 and x86 64) or b) support only a small subset of applications.

Really, as much as I'd love to see Debian update faster, I'd hate to see them take one of those expediencies to get the job done.

Re:Best intentions...

[Dan Ost]

The reason why Gentoo can release predictably and why Debian can't is that Gentoo allows
different profiles for different architectures (Gentoo 2006.0 may have different stable versions for an app for different architectures, assuming the app is available for both
arches in the first place) while Debian requires that the stable profile for each arch is
synchronized.

Deslyxia.

[LoyalOpposition]

there's-a-new-sheriff-in-town dept.

I can see I'm not the only one who read that as, "Anthony Debian Elected New Town Leader."

-Loyal

Worst idea ever?

[babbling]

Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

I don't really trust distributions that guarantee a release every 6 months, because I get the impression they must be rushing things. I'd prefer something quality, even if it's usually "behind the pack".

Re:Worst idea ever?

[Bogtha]

Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications. So long as the base Debian system maintains compatibility between releases (and I was under the impression it did), it shouldn't matter to the applications when new versions of the OS is released, and it shouldn't matter to the OS when new versions of the applications are released.

By tying the two release schedules together, you essentially make the OS wait for the applications to catch up in stability and make the applications wait for the OS to catch up in stability. If one or other can be made stable independently, there's no need to slow things down by synchronising their schedules.

Re:Worst idea ever?

[Spazmania]

More to the point, I'd hate for them to release twice as often period. I maintain more than 60 machines; frequent release upgrades would be a serious drain on my time.

If you want a distro that does significant upgrades to core packages every few weeks, get Fedora. Its great for that. Sucks for stability, but it has a really fast upgrade cycle.

Re:Worst idea ever?

[croddy]

I would definitely agree. It is unusual (in the Linux world) that Sarge took two and a half years to release, but I think that the benefits of the Debian QA process are very apparent. Taking the time to sort out bugs as well as they do -- on a very large number of packages -- makes a Debian release worth waiting for.

The slower release cycle is offset by two things. If you know you need a fresher system, and are willing to sacrifice some stability for updated packages, you have as many choices as you can handle: adding a few packages from testing to your stable system, directly tracking testing or unstable, some mix of any of the three, or even adding packages from experimental if you really want to go out on a limb.

The power of Debian is not only in APT, but in Debconf, the configuration system. Configuration changes are pretty much a given on a system that's directly tracking sid, but are unheard-of (and perhaps even forbidden?) in the stable release. The ease of administration that comes with knowing that changes Debian stable will consist only of backported security patches makes it worth the wait.

Lastly, a system administrator does not want to have to go through a major operating system upgrade on numerous heterogenous servers every 9 months. Knowing that it will be somewhere around 18-36 months between Debian releases means spending a lot less time migrating and fiddling with systems just to keep up with supported releases.

Other distributions do release every 6-9 months. It's not for me... except when it is, and I use testing/unstable in those cases :-)

Brandon replaced after only 1 year?

[JSBiff]

I don't really follow Debian politics much. But, I remember seeing just last year that Brandon Robinson had been elected project lead (he too was planning to put Debian on a faster release cycle last year as I recall).

So, did Brandon resign the post, or did the Debian voters just decide that 1 year of Brandon was enough? I presume that Debian must elect a new leader annually? Are incumbents allowed to run for a second term? Did Brandon run again? Can anyone provide a post-mortem of Brandon's year - was it generally considered that he did a good job in the post?

Re:Brandon replaced after only 1 year?

[laptop006]

Annual term as DPL, Branden decided not to stand for a second term.

Re:Brandon replaced after only 1 year?

[joeytsai]

LWN has a pretty decent interview of Branden, but he's kinda vague about interesting details. Link here.

Changes

[Hellboy0101]

There used to be a time when a new Debian leader election would not have been relegated to a sub headline on Slashdot. I agree with others on this thread that excess architectures need to be dumped, and a firm timeline needs to be put in place. I say putting out a new Stable release every 12 months is the way to go. Debian has an excellent reputation for it's performance and stability. Six months is too soon to keep up that reputation. A new Testing release would be available every six months. With security updates on Stable being current version minus one (i.e. Debian 3.2 comes out, Debian 3.1 will still be supported, but 3.0 no longer will be).

Re:Debian

[Arkaein]

I disagree that Debian Testing's packages work better than Ubuntu (or at least Kubuntu, in my case). I used Debian Testing for nearly two years, but late last year I decided to give Kubuntu a shot and haven't looked back. The final straw was a large set of KDE updates. I had a version of Amarok that I believe was either broken or had some key bug that was fixed in more current versions, but due to some kind of broken dependency chain in Debian Testing there was no way to upgrade anything KDE related. It was like this for a couple of months when I finally left.

There's also the issue that once Debian Testing updates a core package, updating dependencies of that package all require the new core package. Again, this was an issue with many KDE apps. I might want to update Kate, but if the KDE core went under some minor bug fix version change then I have to upgrade EVERYTHING in KDE just to upgrade or install one app. Even the small chance of serious breakage made this a serious risk.

With Kubuntu I know that my software might be as much as 6 months out of date, but I've never had a problem installing or upgrading software, including from the Universe and Multiverse repositories. I can wait 6 months for most things.

It's all about tradeoffs. For me K/Ubuntu strikes the right balance between freshness and stability. Neither Debian Stable nor Testing are as good a fit. YMMV.