IntroductionRob: Good morning, afternoon and evening, everyone. :) Welcome to the Y2K Debian Leadership Debates I'm your moderator, Rob Levin, the head of operations of Open Projects
Rob: we've assembled you all so that we can have a public forum in which the candidates can talk about who they are, and what they can bring to the job of Debian Project Leader as you'll note from the web site, this debate will be divided into two sections: formal question/answer and an informal q/a from the participants to submit a question for the second half, email it to: email@example.com
Rob: please make your questions fairly anonymous; we'll try to prioritize them as best we can, but all of the questions will be posted without headers after the debate, so the candidates and others can look at them and consider them we'll do that raw, so try to be nice, please :) question floods will probably have to be removed, so please don't go there
Rob: our candidates are Ben Collins, Wichert Akkerman, Joel Klecker and Matthew Vernon
Rob: tentatively, we'll provide 3 minutes per answer per candidate during the formal question period we can provide more if necessary, but we want to allow questions for the audience
Rob: when you send informal questions to firstname.lastname@example.org, please m ake sure the header begins with QUESTION
RMS All Free Dist
In the past RMS has requested from Debian a distribution that does not include any non-free software or references to non-free software. Many ideas have been sugested to satisfy this request. What should Debian do, if anything?
AIUI, we already do this to a greater or lesser extent - main contains only free software, and anything that depends on non-free things is in contrib. The question of whether packages should Suggest: or Recommend: non-free things is different.
Matthew: IMHO, it would be better if they didn't, but if there are no free alternatives, then it seems sensible to provide the relevant information
Rob: Matthew: do you have additional comments?
Matthew: I can see RMS's point, but I think trying to hide the fact that <foo> is enhanced by <bar> won't gain us much
ok...IMO, we are already starting to see this form. Like anything it takes time to change how things have been done for so long
BenC: I do believe that we should not completely "hide" non-free, as this is against our current beliefs to support and acknoledge that non-free software exists
BenC: advancements in our archive management (package pools, etc..) and package tools (apt) will allow us to give the users a clear choice as to whether or not they want non-free software
BenC: educating is better then forcing
I think people already know I support the idea; I've proposed doing this last year already,
but it got stranded on the fact that it's hard to split and we didn't really know how do it
and pressure from other things that needed more immediate attention
Wichert: The idea of having a distribution that only uses free software and doesn't need anything else appeals to me, and if we can do it without decreasing our support for non-free software I think we should definitely do it
Wichert: It isn't so much as hiding non-free software, as well as proving that you can live quite well without it We'll always have and support non-free software
During your term the new-maintainer processes was closed by the new-maintainer team. Many people considered their actions to be inappropriate. How should inappropriate unilateral actions by delegates/teams be treated by the project?
New-maintainer might be a bad example of this actually
New-maintainer is a really important function in Debian
people in the committee have the power to make people developers
or remove their developer status.
Wichert: I agree that new maintainer was closed for way too long and something should have been done earlier.
Wichert: However in this case the fact that a) it's a really important job where you can't easily replace people, and b) we had people in new-maintainer who were willing to continue provided there was a good new structure for handling it, I was very hestitant in replacing them
Wichert: I hope that this will prove to be the right decision in the end, but we'll have to see how it works out
Wichert: More generally, I don't think a delegate should be treated much differently in this respect then other maintainers If someone isn't active, we should try to get them more involved and active again If that really doesn't seem possible, we'll have to replace someone
I think it's something that has to be dealt with on a case-by-case basis. In the case of nm - it seems like the problem could have been predicted before it happened. That notwithstanding, if a team decides that it's had enough, we can't (and shouldn't) force them to continue doing their task. I'm proposing to keep in contact with all such groups, so that I can monitor when things are getting tough, and take prophylactic action; prevention being
Matthew: I'm not about to take pot-shots at people about how nm was handled, especially since it's very close to re-opening
Matthew: The important thing now in that regard is to move forwards again.
Matthew: Generally, better communication should prevent this sort of thing though - and I think that's very important.
I think I differ in my assessment of the "new maintainer fallout" in that I think it deals more generally with some core issues in our structure...
Ben: after talking to a couple of people involved with new maintainer I was shown that they were basically asking for help quite a while before they decided to close asking for help indirectly, but still, they asked
Ben: I don't think anyone can point fingers since no one was at fault we were just not prepared structurally to deal with such as event the future holds some very significant changes, in that we need a better structure to handle our core functionlity...things like ftp admin, system admin, new maintainer etc...
Ben: there is not a very well defined strucure insuring that these functions (aside from the people) will go on inthe event that another fallout occurs
Ben: this needs to be changed
Growing unwieldly, AWOL maintainers and delegation issue
Debian's recent growth has been tremendous. The project has nearly doubled its size in all areas. Is this growth maintainable? Should anything be done to make Debian more scalable or to reduce the growth?
As I said in my opening speech, communication seems to be the key to maintaining growth.
Matthew: The DPL needs to keep in touch with the various groups (ftp-admin, nw, qa, and so on) to ensure that they're happy and everything is going OK. Tasks that used to only need one or two people will need to be taken on by more people, and the DPL will have to co-ordinate that.
ok, I hate to make direct comments on another candidates answer, but hey, this is a debate :)
Rob: BenC: it's permitted
Ben: I disagree that were are in a manageable state right now there are much needed tasks that are impossible to do at this point removing the cruft from our archive in over 4000 packages and 7+ archs is next undoable by any means
Ben: we will have to install better control over our archive...
Ben: communications is also not the single key answer...without a working basis on which to develop (well defined charters for each of the groups), we cannot not know who to talk to , or who needs to make the decisions vital to sustaining our growth
So far we seem to be handling the growth pretty well, and I think it's done is
a lot of good as well. However it will mean we'll have to constantly look at
our organization and see if it needs to be changes. We already did this by
creating lists like debian-devel and debian-private, creating a new-maintainer
team, a constitution, etc. As I also already said in my openening speech we
will need to focus on areas such as quality control as well.
Wichert: I think we have reached the point were a single person can't keep in touch with everything that is happening in Debian anymore, and we'll need to see how to that influences the project. I think that his year we'll have to figure out how we should manage `projects' that focus more on specific areas of Debian, such as boot-floppies, quality control, documentation, archive management, etc.
Wichert: This will without doubt create some struggles, since it means it will be harder for people to keep track of everything. Hopefully things like Debian Weekly News will help us there.
Debian BSD and Hurd
Two sub-projects within Debian are aimed at developing ports of Debian to the Hurd and BSD platforms. Some of the suggested plans would make these ports considerably different from the Linux platform. How much leeway should these ports have to deviate from the other platforms? Should Debian focus on its core Linux distribution or try to spread to many OSs?
Well, as someone who works on -hurd, I may be a little biased in this regard, but I don't see a problem as such with non-Linux OSs being part of Debian
Matthew: As long as those Oss are free, and they don't conflict with policy in too many ways (GNU/Hurd, for instance has shadowfs (or will do), which means it may not make a distinction between /bin and /usr/bin, for example)
Matthew: I think it's a good thing, but clearly involves some problems that our current infrastructure doesn't deal with very well (Architecture: all becomes less accurate, and there are sometimes OS-specific bugs in packages, for instance).
Matthew: If we can sort these issues out, then I think non-linux ports will make Debian more flexible, and more attractive to admins.
Matthew: We should maintain our Linux focus for the foreseeable future, however.
I think the entire idea of providing alternate OS's is part of Debian's heritage...
Ben: Linux was in this state when Debian first started, so it is not outside of our beliefs, so long as we adhere to the freeness issues, which BSD and Hurd do...
Ben: Obviously the groups handling such ports should hold the responsibility of devising structure and maintainence to allow their OS's to be side-by-side on our archive with Linux...at the same time other developers should be willing to accept these changes and help the groups whenever possible with ideas and feedback
Ben: i think one of th biggest hurdles is the focus on intel-linux specific views bugs and changes that affect only non-intel archs, and even more so, non-linux ports, are not viewed with as much priority
Ben: this is starting to subside to a great extent, but these views need to snuffed completely
This will differ per port; from what I know for the BSD port the strategy is to have a small BSD base system and use the FreeBSD Linux compatability support to run the normal GNU/Linux userland, which means we don't need to do a lot to support it.
Wichert: For the HURD we will probably see that more HURD-specific packages will arrive, which shouldn't be a problem.
Wichert: Some packages will be difficult though, since they will need major per-OS changes.
Wichert: I don't think that at the moment we really know how we should deal with those, so I think we will have to wait and see where it goes.
Wichert: As for infrastructure, as Matthew already said we will need to make some changes there.
Wichert: At the moment for example we don't have a per-architecture binary-all trees, which will be needed at some point.
Wichert: At the moment we're mostly Linux (and i386) focused, because that's what most of our developers use
Wichert: That might change in the future though, but we really can't predict that
Role of the Cabal
Do some people or group of people have influence or even power that is outside the constitution? If so, is it good? bad? What should be done about it, if anything? If these people don't exist, what do we do to debunk the myth of the cabal?
Of course nobody has any power that is outside the constitution.
Wichert: The `cabal'-theory suggests that a small group of people have (almost) complete power over Debian
Wichert: What actually happens is that a small group of people spent a *lot* of time on Debian
Wichert: As a result this group knows eachother very well, and is active any many areas of the project
Wichert: That doesn't mean that it's a closed group or that it is a powerhouse
Wichert: Anybody is free to join any area of the project, and we actively encourage people to do that
Rob: okay, we have hit time limit
Wichert: you mean my time is up?
Rob: yes, three minutes
Inevitably in an organisation the size of Debian, there will be people who meet with the DPL socially, and so might seem to be able to wield influence over them. In practice, it's a maturity issue for the DPL. I don't doubt that any of the candidates are sufficiently good people in this regard. As to the cabal, there are certainly some people who spend a lot of time on Debian, and/or a lot of time on irc, so may well reach a concensus amongst t
Matthew: These others may consider that a "cabal" is running Debian.
Matthew: Whether these people have any authority or not seems debatable. I don't see how one would quash the rumours of a cabal, though - many of the larger groups I'm involved in have a legendary cabal of some sorts.
Matthew: In a group the size of Debian, accusations of clique-ism or cabals will always be present.
Matthew: As long as there isn't really a cabal, then that's not a problem, IMO.
I think we all sort of agree on this issue...the theories and accusations will probably not completely go away, no matter what is done
on one had, the real-time interaction between developers on IRC< or in real-life, is a good thing...
things get done rather quickly, and with little or no fuss...which feeds progress
bogging things down with "politics" is usually not prefered
Ben: however, the downside is that this gives an air of "closed-door" policies
Ben: people feel left out...
Ben: so the end result will probably involve some sort of medium... and each case is different on what this medium is, and thus subject to opinions to be honest, I don't know how to keep this from reoccurring, but if I am DPL, I will work to reduce it
Money, and Ideals
The recent run of IPOs and startups has made alot of capital available to the free software world. How should this relate to Debian and its ideals of being a free and technicaly excellent distribution? How much influence should commercial entities (particularly those doing development on our base) have in the project?
hmm..veryt broad question for 3 minutes :)
Ben: mainly I think we should just keep to our goals...provide a vast selection of software in the most stable format...
Ben: the minute we start to let commercial influences affect our decision making, is when Debian stops being Debian
Ben: we should simply recognize that we are more in the view of these entities, and not ignore them...just accept them as big groups of average users :)
Wichert: we are already influenced by this we have seen people that want to become a Debian maintainer for the sole reason of being able to participate in an IPO We also benefit from it
Wichert: Without this huge interesting in Linux and capital becoming available we wouldn't have the resources we have now.. VA wouldn't hire 2 Debian developers fulltime for example
Wichert: It also affects our developers, since some of then have benefited from their involvement in Linux or free software in general
Wichert: I don't think it has influenced or will influence Debian itself though we are still all about making a free operating system as an open project and I don't see that changing us
IMO, Debian will (and should) remain a volunteer organisation. That's the nature of what we are, and it's important. That way we can concentrate on making the best distribution, without worrying about commercial pressures.
Matthew: To answer the question of how commercial entities should influence us - I don't think they should have more influence than normal users
Matthew: I think the mainstream-ing (is that a word?) of Linux can only benefit us, in terms of attracting more competant developers (and hopefully money :) ) to the project
Matthew: In 10 years time, I still see us as the best distribution in the World :)
Rob: okay, we'll move on to the next stage
Rob: I apologize to everybody for the time; it's really a difficult thing to fit this all into a fixed format
Rob: we break for up to 10 minutes
Rob: during that period we'll unmoderate
Rob: please, candidates, be very quiet during the break :)
Jason: I will be posting the full topic list to the mailing list, we originally had 12 to ask
Rob: okay all....bearing in mind that at least one of our participants has time constraints (must leave in 15 minutes)
Rob: we're going to do two short time questions and then provide a brief summing-up
KDE and Debian
Debian's current stance on KDE is to not include it. The KDE programmers and other distributions have no problem with the license the way it is currently. Should Debian change it's stance on the KDE licensing issue?
Well, AIUI, the problem is that some KDE stuff includes GPL
code, yet the QPL isn't GPL-compatible
There's been much discussion of this on -legal
Matthew: My stance is that if it's OK to include it, we should include it. If it's not, then we shouldn't. Simple as that. I leave the licence experts to decide which is the case. What other distros do isn't relevant - we must do what is right, IMHO
Wichert: I can't do anything but agree Debian is all about free software, and we should not allow something like this to slip by if possible we should help them resolve these issues so everyone will benefit but it is a real problem at the moment
Ben: I think this is a real legal issue..., one which can't be decided on opinion alone I agree with matthew and wichert...but the solution isn't very clear and I am no lawyer :)
Release Cycle and Package Pools
What will you do to accelerate Debian's release cycle?
With debians growth and nearly 5000 packages it has become clear that it has outgrown the current package system. Also with the slow release cycles it seems that there are only "broken" and "obsolete" distributions. My question then, is if you would like to instate package pools (described at http://lists.debian.org/debian-project-9910/msg00052.html). And if not, what other alternatives do you see fit?
I've not looked at package pools in great detail (and dont' have time to do so in 2 minutes). As to release cycles, I think we need to allow less time between one release and the next freeze - so we can then have more frequent releases, without shortening the freeze time
Matthew: Shorter times 'tween release and next freeze would get less bugs into the distro. With more attention payed to QA, we could get many people working specifically on the release targets for the next release to.
Matthew: And less new things in a release would mean less bugs too - we have to get a balence between very frequent releases with very little new things in (one extreme which CD vendors will hate), and infrequent releases (with the previous distro rather out-of-date).
Matthew: At the moment, the balence seems wrong to me, and I think a shorter release cycle would improve this.
I see the package pool structure as an enabling-technology (to coin a suit buzz-word, even though I hate them :), and faster releases as a result
Ben: how we achieve this is going to depend more on the inbetween, where we decide how to leverage this new structure as most know, Guy decided that package-pool was the way to head, and Jason and I have been working on trying to implent it using LDAP as the core repository...so things are progrws (slowly because of the current release taking time) after the pool is in place, we will need the ideas and work of other developers to leverage it s/progrws/progressing/
as ben said work is already in progress on package pools, which seem like a really good idea to make it easier to play around with the release process
our release manager already stated he would like to freeze quicker (iirc he mentioned 3 months after the release), which should help as well
hopefully the combination of the possibilities and flexibility that package pools provide and a faster release cycle should produce a better and more up to date distribution
not all the focus needs to go to packaging and package systems though..
Wichert: we need to shift the focus towards other areas such as active QA and documentation those are becoming more and more important, esp. with our growing userbase
Rob: okay....now, with the permission of our candidates, we'll do one minute summaries of everybody's broad goals and views I'm going to just pick somebody to start, at this point it's hard to see that we've created any patterns :)
I hope that I have gotten the point across that I am more interested in internal Debian workings, than on outward views on Debian by others...
I say that because I am a firm believer that you cannot change the way people view you by changing them, but more so by changing what you do...
Ben: if we concentrate on our work...it will pay off and others will recognize what we have and will do
Over the past year I've learned a lot about how Debian works, and where it needs some improvement
Wichert: this is hard :)
Wichert: I think we'll need to realize that nothing everything is about producing packages and I'ld like to help Debian grow in other areas
Wichert: we already have a lot of people working on packages and technical issues, and that seems to be going quite well
I want to keep Debian the best technically. At the moment this means dealing with the great expansion of Debian (which is a good thing, but brings its own problems). Communication seems to be the thing, and encouraging developers to consider things such as QA and documentation as well as packaging. I've experience of dealing with disparate groups of people such that they can work cohesively together,
Matthew: particularly as various bits of debian begin to be run by groups of people who may not be involved in the other groups running bits of debian (if that makes any sense).
Matthew: Beyond that, Can I just encourage everyone to actually vote? turnout always seems rather small for DPL elections.