Slashdot Mirror
Debian Project Nominations Opened
robstah writes "The Debian project have announced the opening of nominations for this year's Debian Project Leader (DPL) elections. The first nomination, that of Matthew Garrett (of Dasher fame) has also been announced on Debian Planet."
Other than maybe Eben Moglen, I can't think of anyone who would defend the purity of Debian more strongly than Richard Stallman. The Debian project has always been about providing a Free operating system that works great rather than a semi-Free operating system. This is in line with RMS's original goal of Hurd (which is booting now!).
Let Freedom ring!
Sounds like democracy on steriods. large projects need benevolent dictators!
A wise man once said: If Debian spent less time encouraging politics and more time developing, packaging and testing, Debian stable would have more up2date software versions.
I forgot who said it. Doesn't matter anyway.
"Developers" really means "members of the Project". The term refers to the reality that Debian is a technical project and doesn't have a lot of need for people who can't do actual software development.
As for why only Project members can be the Project Leader, that's pretty common in organisations of all sorts.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002.
Don't let that stop you trolling, though.
deus does not exist but if he does
Will "sarge" become "stable" under the new leader?
The DPL does not have near as much control as someone might imagine. The single most important power of the DPL is the power to appoint developers to admin positions. Debian is less of a democracy than it is a bureaucracy.
The Debian Constitution specifies how certain positions are appointed, and if you read carefully you'll see that many of these positions are completely immune to the DPL. The Project Secretary, for instance, has to agree with the DPL for a new Project Secretary to be appointed. OTOH, the Project Secretary can "delegated authority for a decision" without any outside review. They could, in fact, keep the title and appoint whoever they want to do the actual work.
The Technical Committe is another group with no meaningful outside review. The DPL can only appoint Developers to the Technical Committe when the Committe itself recommends them. If the DPL refuses to appoint the members they recommend for so long that the committe gets down to 5 members, the committe can appoint new members without any input from the DPL.
What about the other delegated positions? Technically the DPL appoints and removes these people without restrictions, but in reality his control over every single delegated position is limited. The Constitution states explicitly, "The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made." Ok, so he can't fire someone because he disagrees with their decisions. But the constitution says delegates "may be replaced by the Leader at the Leader's discretion", so what does that mean? Quite simply it means that delegates are appointed for life. New DPL's don't get to appoint new delegates. To get rid os a delegate the DPL would have to come up with precise reasons for removing them that are unrelated to the technical decisions the delegate has made.
And where do you really see this in action? The single delegate most often complained about is the DAM. He has complete veto power over who gets to join the project and can kick any developer out of the project. For up to six months at a stretch the DAM will refuse to do any work related to the position he has been delegated. In fact, it got so bad recently that the DAM allowed another developer to take over all of the actual DAM work while still remaining in the DAM slot.
And where do the unacountable delegated positions fit into the organization of Debian? Everything that Debian does gets passed through a delegate at some point. The FTP-Masters have veto power over every package. The DAM has veto power over who gets to join the project. The Technical Committe has veto power over policy decisions. And even worse than that, many of the different delegate positions are held by the exact same people. Pick a few members out of the organizational list and look at all of the different positions they hold....now try to imagine any DPL attempting to oust one of these developer from one of their delegated positions.
So....will a new DPL be able to work harder and get Sarge out the door? Of course not. They can beg or whine about it, but Debian's bureaucracy holds all the real power to make things happen. The DPL title is a little perk that core members of the bureaucracy pass around from time to time.
Don't get me wrong. I'm not trying to suggest that all of the delegates in Debian are evil people or anything like that. I'm simply pointing out that voting != democracy and DPL != control.
Debian's releases are always done when they're done. If you want sarge, install sarge -- I've been using it for many moons on production systems. The occasional breakage is still less than what some other distributions shove out the door in their production releases.
I seem to recall a breakage some time ago... think think think... it was a naming conflict between djbdns and the Courier MTA both wanting to install some support program or other. It was an easy enough fix. Other than that, I've had no trouble out of it in either server or workstation usage.
Warning: This signature may offend some viewers.
Sigh, the folks who modded this funny have obviously never used Debian Sid for awhile.
Look, for cryin' out loud people, there are people like me who been running on Debian Sid (unstable) for YEARS. At least 5 so far, long enough that I can't even keep track, and in all that time I can count the number of serious problems on just one hand (and yes, I only have 5 fingers per hand just like all other humans).
All it takes is some common sense to have great stability with the up2date software you want. The rule is really simple, if a little heretical: DON'T USE APT-GET. Use aptitude; upgrade what you need and keep everything else on hold until upgrades are forced because of dependencies. Don't bloody update everything everyday, thats just asking for trouble. Only upgrade on significant version changes, don't upgrade large packages when they first hit debian.org, wait 24-48 hours and see if anything bad shakes out. Really people, its not that hard.
Sorry, for the tissy response, but those of us who KNOW FROM EXPERIENCE that Debian Sid is not "broken" are getting really tired of the lame jokes.