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?

[Robot101]

RMS is not eligible to stand because his new maintainer application has been stalled at the tasks and skills phase due to a lack of time on his part... :P

Re:RMS?

[Anonymous Coward]

G'day Mr Troll,

RMS plays an important part in the free software world, but he would not be suited to a role such as leading Debian. Leadership of such a project requires compromise, and RMS freely admits that he is not going to compromise his Free Software ideals (and he is right not to).

I think you know this too, and are just tryng to start a shit fight. Get lost.

Re:RMS?

[0racle]

Well considering RMS has declared Debian as not falling in line with the pure GNU philosophy by providing closed apps, I would say that he would be one of the worst people to head up the project.

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?

[kubrick]

US law doesn't extend over the entire planet. Yet.

Re:RMS?

[LukaFox]

That's why I said 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.

Re:RMS?

[Bloater]

Mine does, and DVDs too. My parents computer has Windows XP, it doesn't play DVDs even though it has a DVD drive.

Re:RMS?

[hatrisc]

No, Debian GNU/Linux. It's perfectly fine for the name of the entire distribution to be called 'Debian.' It's not perfectly fine to call Linux just Linux when refering to the Linux kernel being bundled with a distribution of software. If you are refering to the 'Linux kernel' by itself it is ok, to refer to it as Linux.

Re:RMS?

[Lord Kano]

This is why linux isn't more accepted. I mean, why not support mp3 out of the box?

All of the Mandrake and Red Hat systems that I've built for the past 6 1/2 years have been able to play MP3s.

WTF's wrong with you?

LK

Re:RMS?

[stoborrobots]

compare them, I urge you.

Why? They are fundamentally the same, as they both readily admit...

From the links: DFSG:

The concept of stating our "social contract with the free software community" was suggested by Ean Schuessler. This document was drafted by Bruce Perens, refined by the other Debian developers during a month-long e-mail conference in June 1997, and then accepted as the publicly stated policy of the Debian Project.

Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create "The Open Source Definition".

Other organizations may derive from and build on this document. Please give credit to the Debian project if you do.

OSI Open Source Definition:

Origins: Bruce Perens wrote the first draft of this document as "The Debian Free Software Guidelines", and refined it using the comments of the Debian developers in a month-long e-mail conference in June, 1997. He removed the Debian-specific references from the document to create the "Open Source Definition."

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?

[PornMaster]

Yay Linus!

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.

Re:why every year?

[ImpTech]

They also have less to do. In the case of FreeBSD that means they support less architectures, and put in less work on their non-core "ports" packages. Of course NetBSD supports every architecture there is, but has relatively few packages if I remember.

I'll readily agree that Debian could be much, much more efficient. But it should be remembered that they're trying to do quite a bit more than most other projects.

Damn that's SMALL LINUX

[Anonymous Coward]

Get the tiny Debian

Re:Damn that's SMALL LINUX

[Living WTF]

Sounds kinda self-ironic ...

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

[msully4321]

I use Slackware, but lets not decieve ourselves. Slackware is not as up to date as Debian unstable (some would say that is a good thing, though), and uses alot of Debian patches for it's packages.

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.

Re:Politics...

[Brandybuck]

That ain't the way I Hurd it!

</joke>

Re:Politics...

[sirReal.83.]

You clearly have no idea what 'stable' means. Look into how often RHEL changes.

Re:Politics...

[Baloo Ursidae]

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.

Therefor, your wise man is an utter moron who hasn't the faintest clue about Software in the Public Interest's ambition. Debian is the largest software distribution out there, on 13 architectures and three kernels. It takes a long time to port and test all that.

Re:Politics...

[runderwo]

You could say that about any corporate software development house too. The reality is that the process instills trust and a sense of reliability in the customer (the user). The customer knows what to expect from Debian, and knows that this won't change tomorrow, because the reins of the project won't be arbitrarily handed over to a new person who happens to be ill-suited for the job either in technical ability or temperament.

Re:Politics...

[runderwo]

I already replied to this, but found another post that says the same thing in (IMO) better words.

Re:Politics...

[sirReal.83.]

RHEL2.1 has a lot of the same stuff that Woody has, and a lot of Red Hat's customer's prefer RHEL2.1 to RHEL3 *because* that software is older.

Right, Fedora is more stable than Debian unstable. Maybe that has something to do with the fact that Fedora Core releases are... releases? Go track rawhide for a few months and tell me some stories about it. I certainly have my share - I use rawhide at work. I use unstable at home (I have only one machine). One definitely breaks more than the other. And about 'stability' - it has nothing to do with crashes - that's called 'bugginess'. People in software talk about stability to indicate API and ABI compatibility.

Debian releases based on critical bug counts. Politics are a problem, but they don't affect release schedules as much as you think. Fedora releases don't generally slip for any reason.

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:The question is:

[asackett]

The security updates aren't as "timely" but they do show up.

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.

if not GFDL, then what?

[bcrowell]

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., and nearly all of the objections seem to be completely irrelevant if the document doesn't have any of those things in it. (I do dislike the political nature of the preamble, the length of the license, and the difficulty of understanding what consititutes a transparent copy.)

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?

And in the meantime, what does Debian plan to do about documentation that is already GFDL'd? It seems ridiculous to refuse to distribute docs just because they're GFDL licensed, especially if they don't have any invariant sections.

Re:if not GFDL, then what?

[sirReal.83.]

If "nobody uses" invariant sections, front-cover or back-cover texts, and those parts of the license make it nonfree, then why are they in the license?

Even if it were true, that nobody uses them is irrelevant. If someone specified "GFDL with no invariant sections or *-cover texts" then Debian is okay with that anyway.

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.

Re:if not GFDL, then what?

[m50d]

Yes, CC attribution-sharealike is I think the preferred license. Personally I go for a little gem called the Design Science License that's hidden away on the GNU website.

In the meantime, they treat GFDL docs the same way they treat propriety software. Which is the only thing they can do. Although IMO something with no invariants is currently free, just could become non-free, and should be treated like BSD-licensed software.

Matthew Garrett

[St. Arbirix]

...of Dasher fame? He hasn't done anything else? That's his qualification? Some people take Democracy too far.

I'll admit Dasher is kinda cool but its really not all that complex. It'd be like MS putting the guy who thought up MouseKeys in charge of Windows.

Re:Matthew Garrett

[perky]

IIRC he seemed to be pretty clued up on all sorts of things if the ucam.* groups can be trusted.

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.

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

Re:'unstable'

[hummassa]

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

That it changes?
Now, it's interesting you mention Ubuntu... as I really opted for it six months ago... I am posting this from a Warty+KDE machine and my laptop is a Hoary machine, ie, Sid.

Release Sarge?

[Spazmania]

How about nominating someone who will put a higher priority on getting Sarge out the door than on the purity issues?

I like Debian's reliability and I've used debian as my primary OS since around '96. I also live in the real world where non-OSS commercial software gets used. The libraries in Woody have gotten too far behind current. Sarge needs to get out the door soon if Debian is going to remain viable outside of the core clique of maintainers.

Re:Distribution Names

[True Grit]

I've used Debian Sid some years ago, and once I needed an additional package. It did install and (due to dependencies) updated an other package, In which some dependency was missing, so it didn't work. I figured out what other package it should have depended on and tried to install it, but couldn't because this package had dependencies which couldn't be fulfilled. That's what I call broken.

No, its only "broken" if the breakage reaches your machine. In your example, use aptitude and put all packages that can't be upgraded because of dependency problems ON HOLD until the problem is fixed. The maintainers hear about the problems and usually fix it within a day or so. Sometimes it may be several days before some critical library is updated to fix a dependency chain mess, but NOTHING ON YOUR SYSTEM IS BROKEN IF YOU JUST HOLD EVERYTHING AND WAIT FOR THE FIXES. Patience is all you need.

What is happening with Debian, really?

[claes]

I ran Debian for a year or two around 1999-2000. I liked many parts of it, but over time I got frustrated of following its progress since it was so slow. I have followed several Debian project leader elections over the years, at a distance, by reading the candidate's programs, and no matter who is elected, the slow progress continues. I must say - what difference do they really make? I understand that there could be lots of important stuff being done in the background, but my impression of Debian is that it is a stagnating distribution. Very conservative, moving very slowly. This can be good, but I think also it is dangerous.

Can someone mention the three most positive things going on in the Debian community right now. What will Debian bring in the near future? What makes Debian of today different compared with Debian three years ago?

Re:Distribution Names

[runderwo]

You can use apt-get for this too. Just specify a default release in your apt.conf. If you want to pull a package from unstable, then apt-get -t unstable install and it, along with its dependencies, will be pulled from unstable; any normal apt usage will pull from testing or stable (whatever you gave as your default release).

I would have to agree that installing a package as soon as it hits unstable is a bad idea. You can go to packages.qa.debian.org to see how long it's been since a package was uploaded, along with any pending issues with it.

Re:Distribution Names

[True Grit]

but it happened to me.

Me too. It doesn't happen often, but when it does, just put all the affected packages on hold until the broken package is fixed.

It takes a little time to get up to speed with aptitude (its UI is very functional but not exactly user-friendly), but once you do, its easy to "hold" packages so that nothing breaks on your system until the dependencies are fixed on debian.org, at which time you just "un-hold" the affected packages and let them upgrade as normal. Aptitude lets you walk a package's dependency tree, forwards and backwards, so its easy, once you've done it awhile, to find and hold an entire tree of dependencies that are currently "broken". Afterwards, every once and awhile, you try to unhold the primary package and see of the dependency problem has been fixed. If it has, let aptitude, via apt-get, upgrade the packages, if not, put the packages back on hold.

If you get conservative, and just start keeping most stuff on hold unless its something you want or need, then this problem gets even rarer, because often the problem packages may now already be on hold and thus you never "see" the problem at all.

It does require a different mindset from the typical use of apt-get though. apt-get is primarily designed for the upgrade from one fixed version of Debian to another, but when using it to constantly update from a moving, changing target like unstable/Sid, its usefulness really falls apart. To keep your system going for long periods of time in light of daily changes like that, you simply have to get more conservative and adopt an attitude of "only mess with the stuff that I really need".