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."

Comments

RMS?

[Dancin_Santa]

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!

Re:RMS?

[psamuels]

Guess that depends on what you mean by freedom. Richard Stallman disagrees quite publicly with the Debian Project in the matter of the GNU Free Documentation License the Project does not consider it sufficiently free.

Some of you will think it is heresy to regard a license from the Free Software Foundation as insufficiently free. Heresy or not, though, I agree with the Debian Project: the GFDL imposes some onerous restrictions on what users can do with the licensed work, and Stallman seems unwilling to drop some of these restrictions.

As it happens (bringing us back on topic), the first nominee for Debian Project Leader 2005, Matthew Garrett, features prominently in the above document detailing why RMS's documentation license is not free enough.

Re:RMS?

[LukaFox]

These things can be done by free software. The reason that some distributions don't include software that does this is the issue of software patents. It's not that the software doesn't exist, it's that it might be illegal depending on patent law.

Re:RMS?

[Anonymous Coward]

This is why linux isn't more accepted. I mean, why not support mp3 out of the box? People look at linux and say "it doesn't even PLAY MP3s!" Yes, yes, we all know you can just install mplayer or something like that but it's stupid.

OK, I'll bite. When you install Debian you have two independent choices to make: (1) do you want non-free packages? Y/N, and (2) do you want non-US packages? Y/N. There are tens of MP3 players in the standard place. The MP3 encoders are in the non-US section (which is transparent, once you select that you want non-US everything is just a one big respository) which you can use even in US. Yhe point is that you have an easy option to opt-out if you don't want to use any software that may be potentially illegal in the US. Every Debian version is divided between: base, non-free and non-US packages, plus a separate respository for fast security updates. Also, you can use any non-standard Debian respository of your choice, which will integrate with your apt-get just fine. There are a lot of packages to download. You can find such packages here.

why every year?

[Anonymous Coward]

how do you get anything done when the leader is changing every year?

Sounds like democracy on steriods. large projects need benevolent dictators!

Re:why every year?

[krmt]

That was tried before. It didn't work out so well. The mailing list archives were deleted with a nice "fuck you all."

Re:why every year?

[Mr.Ned]

FreeBSD and NetBSD seem to get a lot done without a benevolent dictator. One reason for their success may be that there aren't as many 'developers' with commit access - they don't have a 'developer' for every two or three programs in the archive as Debian does.

On a different scale, the Apache project is quite successful without a benevolent dictator, and it's just one of many.

Re:why every year?

[Master Bait]

Hey, I got an idea! Maybe they should work out a system where Debian has three presidents, one elected per year for a three year term on a quasi-lazy Susan, stack-based basis.

The newest president would be called Testing and everybody would go to him for real everyday issues. The second president (second year in office) would be called Unstable and he would work with the greybeards out in the field helping tham to keep their ancient computers running. Then, in the last year in office, the president would be called Stable and he (or she) appears on panels at universitys and trade shows and awards dinners.

Damn that's SMALL LINUX

[Anonymous Coward]

Get the tiny Debian

Politics...

[BladeMelbourne]

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.

Re:Politics...

[jrcamp]

Debian seems to get along just fine. The stable branch, by its definition, does not receive new versions of software once it is released. It only receives backported security patches.

Testing and unstable, on the other hand, are more current versions of software.

Only developers?

[PornMaster]

I'm a little intrigued that the project leader position appears to only be open to developers. Perhaps it's done to ensure that the leader is aware of all of the complications involved at lower levels, but I have to wonder if it's always best to have a project led by one of the foot soldiers.

Re:Only developers?

[krmt]

Debian Developers all have GPG keys that are signed by other Debian Developers, and are thus in the web of trust. The project would have no way of verifying that someone outside that web of trust even exists. Furthermore, their conduct within the project allows an easy reference point in choosing a candidate.

Re:Only developers?

[psamuels]

"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.

The question is:

[Living WTF]

Will "sarge" become "stable" under the new leader?
Or is this going to become some "Real Soon Now" / "When It's Done" thingie?

Re:The question is:

[Anonymous Coward]

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.

Re:The question is:

[asackett]

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.

Re:The question is:

[Bishop]

It was originally promised for Fall of 2003. After the last debian elections a commitment was made for October 2004. I can't remember if that was a code freeze or release. Regardless, the release has slipped.

Some developers are obviously frustrated. They have worked hard on their packages, and have even helped on other packages. Other developers simply don't care if Debian ever releases again.

Re:Does this mean...

[kubrick]

Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002.

Don't let that stop you trolling, though.

RTFC

[mincognito]

large projects need benevolent dictators!

Or a well-formed constitution: http://www.debian.org/devel/constitution

Re:Distribution Names

[True Grit]

to stale, rusting and broken...

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.

Re:if not GFDL, then what?

[psamuels]

I think a lot of the complaints about the GFDL are overblown. Personally, I've never even run across a GFDL'd document that contains any invariant sections, etc.

Several GNU manuals include the GNU Manifesto as an invariant section -- in fact, I can't back this up, but it certainly appears that the main motivation for the invariant section clause was specifically to prevent people from removing the GNU Manifesto from GNU manuals.

As others have said, there are quite a few onerous and ambiguous clauses in the GFDL; it's not all about invariant sections. Some of these seem to be mere bugs in the license text, rather than in the intent. Others, like the requirement to cram the whole text of the GFDL onto anything (even, say, a reference card) derived from GFDL'd works, are annoying but not necessarily non-free.

Certainly, the non-modifiable sections of a GFDL work cause the most fear and loathing. If you really think none of those problems could happen in practice, please see this message for a scenario I find very believable.

But anyway, if Debian doesn't like the GFDL, what does it like better? The CC share-alike license? Would the CC share-alike-attribution license be ok?

Creative Commons (in particular the Attribution license) seems to have its heart in the right place. Depending on whom you ask, there are a few "bugs" in that one too, but they seem to be relatively minor nits. As such, there is hope that the Debian legal eagles can negotiate with Creative Commons to iron out problems for future editions of the CC licenses. Certainly the two groups are talking to each other.

Meanwhile, there's no reason you can't use your code license for documentation -- be that the GPL, or some BSD-like thing, or what have you.

And in the meantime, what does Debian plan to do about documentation that is already GFDL'd?

Consensus seems to be that the GFDL has enough problems that even without invariant sections, it's not a free license. As such, the convenience to the user doesn't outweigh sticking to principles of freedom. Just as it did not in the case of Netscape 4.x, which was by far the best graphical web browser for Debian platforms in its day, but didn't ship with source code. If users want manuals, they'll have to point their /etc/apt/sources.list at the non-free section of the archive. In practice, including "non-free" in your downloads is really no inconvenience at all, unless you've only got Debian CDs and no net access, and the CD vendor chose not to include documentation packages from non-free. (This is something a vendor can choose to do, if they wish to take the trouble to comb through the non-free archive to see what they can legally ship at all.)

Curiously enough, practical problems of documentation are mitigated a little bit by a completely unrelated issue. The GNU Project tends to spurn "man pages" as a documentation format, so most GFDL documents are other format documents, such as info pages. The Debian Project still likes man pages, so there are a number of contributed man pages in GNU packages in Debian which were not from the GNU upstream.

'unstable'

[DavidNWelton]

Look, it's called 'unstable'. What sort of impression do you think that gives people?

One of the reasons people use distributions is to get a stable set of packages that work with one another, instead of having to pick them all out by hand. Your method above is basically reverting to hand selection, and is not really something that is acceptable outside of a hobbyist setting. One of the reasons for Ubuntu's instant success is that they QA'd a bunch of recent packages, and released them as a distribution.

This situation has, from my observation of things, led to a lot of people abandoning Debian for things like Ubuntu and Fedora. I guess it doesn't matter all that much - we're not going to lose out on any revenue;-) - but it's a pity, as Debian use to have an excellent technical reputation.

I suppose marketing types might say that Debian has mismanaged its brand or something like that, becoming known for the "freeer than thou" political battles with the FSF, and having a very out of date distribution rather than technical excellence. Hopefully, we can get that back, but it will be tough.