Author: Bruce Byfield
Linux.com: What are your first priorities as Debian Project Leader?
Sam Hocevar: The first thing I need to do is to gather information about current internal conflicts and tensions that could prevent certain people from working together, or at least make those organisational changes require more diplomacy.
I plan to focus on the social part of my platform, mostly because they require more time to do properly. People didn’t wait for my election to start doing the technical stuff I talked about: We have a Google Summer of Code project for a Web interface to our bug tracking system, at least one tool is under development for the debugging infrastructure, and quite a few proposals about improving the Web site have popped up.
LC: In your platform, you talk about “conservatism” and “control freaks” and “an important concentration of powers amongst a very small number of individuals” as being part of the problem with Debian today. Can you explain more?
SH: The concentration of powers, when combined with conservatism, can really block a project. It isn’t as bad as that in Debian because these people are competent and have Debian’s best interests in mind. However, the problem of time and availability has often been raised (tasks that could be done faster, ignored or dismissed requests).
We’re also seldom mentioning the “What if Joe Random Developer gets hit by a car” argument. A few Debian developers have already passed away and as we grow older and more numerous, we should expect even more unfortunate events. And speaking of growing older, this is exactly the same as the “What if Joe Random Developer becomes uninterested, gets a job, gets married, has a kid” argument. This is why I think we need fresh blood: Not only to maintain packages, but also to work in our core teams. Otherwise, we’ll wonder what to do when it’s already too late.
LC: Why do you think that the Debian project needs to work more in teams? And how would you encourage their creation?
SH: Each time a task has been waiting for a very long time because the person in charge doesn’t have time to do it and someone else could have done it but cannot because they do not have the credentials, a team would have helped. And these things happen all the time.
As I said in my platform, I want to reduce the conception that packages are owned [by their maintainers]. I have no constitutional right to enforce this way of thought, but I can encourage people to be bold and fix bugs in other people’s packages, to do non-maintainer uploads, and to create teams for badly maintained packages. These are often seen as hostile acts because they question the maintainer’s abilities; we should get rid of that idea, too.
A common criticism of this opinion is that allowing anyone to do anything leads to lack of commitment and that people start to think that they don’t need to be very precise and thorough because someone else in the team will fix their mistakes. I don’t question the validity of the concern, but I am not suggesting that anyone can do anything. With minor selection of who joins teams, the benefits clearly outweigh the detriments.
As soon as someone understands they’re having trouble maintaining a package, they’ll understand the benefits of a team. But I don’t mind people who do not want to work in a team as long as they are doing a proper job in maintaining their packages.
LC: What are you thoughts about the process by which Debian allows new package maintainers to join the project? What concrete steps would you take to streamline it?
SH: Our new maintainer process is very slow, which is, many say, a way to ensure that the new maintainers are motivated enough.
One of longest steps is the wait for the Debian Account Managers approval (by our constitution, it’s the DAMs who decide whether someone can enter the project). We either need more DAMs or DAMs with more time. There have already been attempts, including from the previous leader, to improve the process, and I plan to continue with these projects.
Unfortunately, the new maintainer team is also overwhelmed. Most of the time is currently spent waiting for an Application Manager (who is then going to follow the applicant during the whole process), and we cannot have new AMs magically appear. I’ll have to dig more into the current procedure to guess how to make their task easier, for instance by involving the applicant’s sponsors more and making applicants help existing teams first instead of having them package new software.
LC: In your platform, you talk about appointing additional assistants. In what areas? Are you concerned that this might cause resentment? Would these positions have to be ratified by a general resolution?
SH: I was mainly thinking about the core teams (FTP-master, Account Managers, System Administrators) but my general message is that if you want to help Debian but are not in a position to do it because you need to be delegated the proper powers, tell me and we’ll see what we can do.
Of course this might cause resentment. And merely insinuating that it might cause resentment might cause resentment, too. That’s why I’m going to study interactions, talk with people, use diplomacy instead of firing everyone and putting new, unexperienced people at their places, so it will take time. But it is also pretty clear to me that I was elected to solve these problems, not just because I was suggesting we have a sexier Web site, so I don’t plan on letting the situation rot.
LC: One point mentioned in your platform was to get more non-maintainers such as technical writers and artists involved in Debian. How would you go about this effort?
My idea was to have them go through the New Maintainer process, too, but without having them do the Tasks and Skills test step (which is not the longest one anyway) but not let them upload packages (which is by far the developer action that requires the most trust). We have a new tool in the works that will make it easier to split our PGP web of trust into roles and deny upload rights to certain roles.
LC: It seems that a lot of what you want to do requires enlisting the aid of dozens of project members. To what extend do you have people ready to work with you? How will you go about finding and enlisting others?
SH: The amount of support I found out I had is amazing. Within 24 hours after the election results, I was contacted by many project members who wanted to work with me, but also people from outside the project: several Web developers, one graphic artist, and people from the Bugzilla bug tracking system offering advice.
I think the people are already there, and just need to operate in an atmosphere void of frustration, where they know their work is useful and not being ignored. This will not only happen if there are people to do the work, but also if the rest of the project isn’t too conservative and accepts the changes.
LC: You sound as though you think Debian has an image problem, especially compared to Ubuntu. What is that problem, and how would you fix it?
SH: While it is reputed for its technical excellence and stability, the Debian operating system has also for a long time been known for being elitist, in good part because its installer did not have much eye-candy. Of course, this wasn’t true any more when we released Sarge, and is even less true today: The graphical installer in Etch is a truly powerful and easy to use piece of software. However, the distribution still carries this image of austerity and lack of user-friendliness.
I have suggested that this may be due to other parts of Debian, such as its Web site or its bug tracking system, not being terribly appealing to the categories of end users who massively switched to Ubuntu. Our Web site is not dynamic enough, has many links but has poor navigation support. We could at least provide some screenshots of the system we make, for instance. Fixing the Web site and general infrastructure has already started.
It has also been said that Debian has an image problem due to regular flaming on mailing lists. I have not found that to be empirically true.
LC: Dunc-Tank, the effort to pay key Debian developers full-time, became controversial, especially since DPL Anthony Towns was involved in it. Will you be repeating any experiments along the lines of Dunc-Tank?
SH: No. I have already stated a few things I plan to use Debian funds for (buying new hardware, sponsoring people to attend meetings), but I have no plans to repeat something like Dunc-Tank that I have actively opposed, and while there is certainly something between “Dunc-Tank” and “nothing” that I might agree with, the DPL being involved in it would be a very bad idea.
LC: Former DPL Martin Michlmayr is working on a thesis about release management that uses Debian as a case study. Do you have any plans to implement some of his suggestions?
SH: Release management has already improved: Etch took one year less to release than Sarge. One of Martin’s main points is the switch from the “release when ready” model to a time-based release process, and I wholeheartedly agree with this view. Unfortunately, it is not the DPL’s job (or power) to tell the release team how to work. I hope they have a look at Martin’s published papers, though.
Looking ahead
LC: How will you judge your success as DPL?
SH: I don’t know, mostly because I don’t know the obstacles yet. I’m not foolish enough to think I’m the first one to come up with all these ideas. It’s just that I don’t know what prevented my predecessors from doing it, or caused them to walk an easier path.
There will be technical indicators for all the technical projects I suggested, but that’s the easy part. The social impact will be harder to measure, though if I manage to appoint new assistants to core teams and if they manage to work together, I’ll be very satisfied.
LC: Can the changes you would like to see be implemented in a single term? Will you run again, if necessary?
SH: Probably not everything can fit in a single term, but there are also many things that either do not need DPL powers at all, or just require the first tiny push and that I can finish even after my term has ended.
I really don’t think I will run again; I need to have a life, too, and, though I’m interested in social studies and project management, I still prefer hacking and programming. I’ll be happier if someone else has an exciting platform and makes me want to vote for it.
LC: Is there anything else that you’d like to say about the challenges facing you, or about Debian?
SH: The task is enormous, but not impossible. Many aspects of Debian, such as release management, have already improved in the past years. It’s a clear sign that people not only want things to improve but are also working on them. And since I won’t achieve anything alone, I will be more than happy to give developers the power to improve Debian even more. All the help is of course welcome!
Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.
Category:
- Linux
