How Debian Almost Failed to Elect a Project Leader (lwn.net)

Five candidates now are running to be Debian's project leader for the coming year. But earlier this week, Slashdot reader Seven Spirals shared LWN's story about what a difficult election it's been: This year, the call for nominations was duly sent out by project secretary Kurt Roeckx on March 3. But, as of March 10, no eligible candidates had put their names forward... There is nobody there to do any campaigning.

This being Debian, the constitution naturally describes what is to happen in this situation: the nomination period is extended for another week... Should this deadline also pass without candidates, it will be extended for another week; this loop will repeat indefinitely until somebody gives in and submits their name... In the absence of a project leader, the chair of the technical committee and the project secretary are empowered to make decisions -- as long as they are able to agree on what those decisions should be. Since Debian developers are famously an agreeable and non-argumentative bunch, there should be no problem with that aspect of things...

One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it. If that were indeed to prove to be part of the problem, Debian might eventually have to consider doing what a number of similar organizations have done and create a paid position to do this work.

Comments

Re:systemd

[Gravis Zero]

Whether you like or hate systemd, it must be a pain to deal with all the drama and hate surrounding it when all you want to do is put out a decent distro.

If it really is such a corrosive issue that reaches everyone then wouldn't it make sense to make it optional, if only to prevent hardship on your packaging teams?

My understanding is that most packages simply need to be rebuilt using ./configure --without-systemd. Would it not be worth making a set of "without systemd" packages to quell the drama and hate?

Less flexible, less reliable

[raymorris]

Comparing "man showpath" with "man traceroute", we find that showpath can do a lot less than traceroute can - it has far fewer options.

One might also notice that unlike traceroute, showpath tries a bunch of ports and hopes - the results of showpath might be similar to reality, the results are often right, often not. Traceroute uses one and the results it provides are correct. (Or in case of error, traceroute indicates an error, as opposed to false results).

So by now I'm sure you see why traceroute had to be replaced by showpath - to make it dumber and less reliable.

Actually the best I can tell, those who wanted to replace traceroute never bothered to check the docs after they heard about a "problem" with tracert which doesn't actually exist. The excuse for getting rid of traceroute is that "you have to be root to run traceroute", but that simply isn't true. There are in fact TWO different ways that non-root users can run traceroute. Like ping, normally it's installed setuid, which allows any user to run a small program as if they were root. You wouldn't want large, complex programs to run setuid in case of security bugs in them, but for small, simple programs it's fine. If you don't want to set it setuid, any user can still run it and it'll do the same udp trick that showpath does. Showpath is literally a small subset of traceroute's functionality. It's not so much replacing one with another, but rather "take away all of the most commonly used options for traceroute and leave only showpath remaining". Genius.