On Wed, Mar 06, 2002 at 07:45:02PM +1000, Anthony Towns wrote: > Some questions for the DPL candidates... [...] > So! On to the actual questions! Candidates, riddle me this... > What do you consider the DPL's field? > - as an intelligent rubber stamp as per the constitution? (ie, > spending money, giving people who're already doing a job an > official "delegation", etc) First and foremost, the above. I don't think its illegitimate to argue that a person holding an office as defined in a constitutional document should give primary emphasis to those duties that document defines for the office. Note that "delegation" doesn't just mean "giving people who're already doing a job" official status. It also, as I emphasized in my platform, meant identifying areas where *no one* is doing a job, and trying to find delegates to handle those areas. > - poltical issues? > - technical leadership? I believe the above two should rest co-equally at a priority right below the Leader's constitutional duties. I imagine which one receives emphasis will be a consequence of the DPL's personality more than any other factor. Or, perhaps, one of these will percolate above the other due to the demands of the day being placed upon our Project. > - design or implementation of technical changes? I see this as definitely of tertiary importance for the DPL functioning as such. Of course, I don't think the DPL should give up doing this sort of work if it intrigues him or her; but seldom is it necessary for technical design to be done as something other than regular developer. > - something else? The DPL should represent our Project to the rest of the world. Talk to the press, appear at trade shows when possible, and attempt to promote the Debian Project to people who are unfamiliar with us and our work. In short, the DPL should try to get others to share his enthusiasm for our Project. > As DPL, how will you ensure the technical goals in your platform are > achieved? It's difficult to guarantee the accomplishment of any particular technical goal. The main reason is stated clearly in clause 2.1.1 of the Constitution: "Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them." <http://www.debian.org/devel/constitution> I think it would be reckless for any candidate to promise that any particular technical goal will be achieved, unless that goal is clearly already on its way and doesn't particularly need the DPL's help (in which case you'd wonder why he or she campaigns about it). > Branden, given that there have been enough other things to work > on and difficulties with the implementation up until now that > this hasn't already been done, how will you ensure qmail is > removed from lists.debian.org? I have not promised to ensure that qmail will be removed from lists.debian.org. I have stated that it is something that I'd like to see accomplished, and that I'd like to put together a team to do a feasibility analysis. This team would obviously have to include current members of DSA, and the listmaster group. To quote my platform: "In my tenure as DPL, I'd like to do whatever is feasible to transition official Project infrastructure away from non-DFSG-free software...Transitioning our list server is no small job, and doing so without disrupting our development process is a serious business. As DPL, I'd like to recruit volunteers to handle this task and prepare a schedule for executing a transition." <http://people.debian.org/~branden/platform.html> I have not made a promise to achieve the elimination of qmail from our list server because, frankly, I don't believe this task is completely within my power. If the people whose responsibility it would be to make the transition absolutely refuse to do it, it probably won't get done. > If you aren't elected DPL, what does that mean for the items in your > platform? Will you spend time over the next twelve months helping > motivate the project, or recruiting people to adopt packages, or trying > to ensure the developer base is active, or any of the other things in > your platforms anyway? I'd like to, yes. I didn't make up my goals for the sake of having something to campaign for; all the items on my platform are something I'd like to see any DPL do. > How well or poorly do you think we've gone at achieving each of the > following? Is there anything you'd have done differently as DPL to what > BenC's done? If so, why didn't you do it just as a developer, and why > would it have done any good? > > 1. Releasing woody [BenC, Branden, Bdale] For reasons you described (in the very large chunk of your mail I excised), I think the woody release is largely out of the DPL's hands. The powers of the Release Manager are greater than those that an ordinary developer possesses. A mere developer doesn't have the authority to declare a release, no matter how hard he or she may work or how much he/she may accomplish. I have done what I can to expedite the woody release. I've tried to keep my packages in good shape as regards release-critical (RC) bugs, and have fixed many RC bugs in my packages. I've worked quite a bit on the IA-64 port to get that architecture into a releasable state. And, of course, I've filed bugs reporting release-critical issues. > 4. "Fishing our cutting bait" on non-free [Branden] Again, this issue is pretty solidly in the domain of the Project Secretary, under the current circumstances. As a regular developer, I had no interest in rekindling the 8-month flamewar that happened when John Goerzen last proposed eliminating the non-free portions of our archive. Manoj, as Project Secretary, established a game plan for proceeding on this issue. First we need to fix a bug in our voting process. Then we need to decide whether and how the Social Contract and Debian Free Software Guidelines are amendable documents. Finally, we can take action on the non-free issue. I agree completely with Manoj's priorities on this issue, even if I have to admit I'm a little disappointed at how long it's taking. On the other hand, I think the delay may actually have been good in a way for the supporters of removing non-free. Back in 2000, a lot of people were furious that some people were "trying to take their Netscape away". That's almost a laughable concern now. Several Free browsers are superior to current offerings from Netscape. As time goes on, I think practically all Debian users are finding non-free Debian packages playing a smaller and smaller part in their daily activities. The $64,000 question is whether this proportion is now so small that we're actually doing Free Software more of a disservice by preserving the non-free section than we would be doing Our Users a disservice by getting rid of it. (See clause 4 of our Social Contract.) http://www.debian.org/social_contract I don't know the answer. That's why I'd like to see the issue come to a vote. > 5. Getting the US government to lift all restrictions on > crypto export [Branden] Heh. Aside from joining the EFF I cannot say that I have done a great deal personally on this issue. This job is quite possibly beyond Debian's scope. It may be that, with the crypto-in-main transition that is now occurring, most of our developers may not care to see US export restrictions on crypto further liberalized. The current regulations, as susceptible as they are to the whims of changing Presidential administrations, may be good enough for the majority of our developers. If that's the case, it wouldn't be right for me to try to crusade on this subject in Debian's name. However, I'd like to take the Project's temperature on this issue before deciding to abandon it. I do in fact feel that we have a bit of a sword of Damocles over our heads by accepting crypto into main under the current regulatory structure in the United States. Things could change tomorrow, and some of our American developers could end up on vacation at Camp X-Ray. (That's a joke...I think.) > How well or poorly do you think we've gone at _avoiding_ problems due > to each of the following? Same qualifications. > > 1. Accumulation of inactive maintainers [Branden] > 2. Accumulation of unmaintained packages [Branden] I don't think we're much *worse* off with regards to the above items as we were a year ago, but we're in worse shape than we should be with respect to both, in my opinion. The good news is that Martin Michlmayr has been doing some great work that may help us to take action on this issue. > 3. Inconsistent timliness of security advisories [Branden] It's unclear to me how much negative impact we have experienced due to this, aside from occasional poor press. As DPL I'd like to encourage the security team to take on more members if they can find trustworthy and motivated individuals with which to grow their ranks. > 4. Version skew amongst architectures hamstringing testing [Branden] This is much less of a problem than it used to be. You (Anthony) occasionally have to send nastygrams to one port list or another, but my impression is that the advent of buildd.debian.org has gone a very long way to alleviating this problem. > Just for kicks, what did you think were the three big achievements > we actually had in the last year, and the three biggest problems we > actually faced? (If you haven't already been horribly biassed by the > list of problems at the start of this message, anyway) I think I'm going to politely decline to answer this question. So much happens in our Project within a year that I think it would take me even longer to come up with a reasonable assessment than it already has taken me to answer this mail. I don't want to slight somebody by overlooking his or her hard work and leaving it off the list, and I don't want to unfairly criticize someone who may be identified with a particular problem (which may be pretty minor when you take the whole year into account). > Top three things you hope Debian will achieve during the next twelve > months? 1) a release of woody 2) Endorsement by major computer manufacturers and or ISV's (like, say, Oracle); I think Debian's profile needs to be higher. There are *still* too many people in the world who think that "Red Hat = Linux". 3) a streamlining of various internal processes and procedures, and better documentation thereof, so that we can function more smoothly and efficiently > Top three problems you think Debian will face during the same > period? 1) regulatory challenges hostile to Free Software from various governments Hrm, I can only really think of that one. I can't conceive of anything else really having the power to stop us in our tracks. > Are there any longer term goals or concerns we should be worrying > about, and, if so, what needs to be done about them in the next twelve > months? As Bdale pointed out, we need to be thinking about decentralizing some services and providing better redundancy for others. It certainly does suck when the http.us mirrors get out of sync, but that's just one example. > Do you think there's anything that can or ought to be done about changing > the trend of the graph at http://bugs.debian.org/~ajt/graph.png ? I think the trend is probably going to be upwards for as long as we continue to add packages to our distribution. It's the nature of the beast. Software has bugs. What would help keep that slope lower, though, would be addressing the problems we have with inactive developers and unmaintained packages. See above. > There are many purely technical subprojects within Debian that would > be useful if completed, but seem like they're not getting any closer > to being ready for production systems. Things like non-interactive > installations (debconf got it started, but we seem to have stalled), On the contrary, I can think of two projects that are still active on this front. One is FAI, and the other is autoinstall. I'm more familiar with autoinstall; as far as it goes, I don't know that very much feedback has been received. Perhaps these projects are insufficiently visible to the people who'd want to take advantage of them. > IPv6 support (debian-ipv6@lists.d.o), I fear that IPv6 is doomed to remain a niche concern until certain entities that have an economic interest in preserving address scarcity abandon that interest. Why have enough addresses for everybody when you can not have enough, and charge people for the privilege of getting and keeping them? Artificial scarcity is possibly the worst economic problem of our age. Why have a free, low-friction market when you can indulge in rent-seeking? > the Hurd port (binary-hurd-i386), The Hurd's problem is different. I think most people don't play with the Hurd because Linux is "good enough". Of course, people said that too about about DOS/Windows/Solaris/whatever when Linux was still primitive, but the GNU/Linux system's licensing gave you an advantage that the Hurd cannot claim over Linux. Therefore, you're missing the group of people who are driven to develop and improve on an alternative because of the unpleasant licensing and lack of freedom in their current environment. That's just my attempt to explain why the Hurd hasn't caught fire yet. I find the project intellectually interesting and I'd like to see it grow and succeed. I further think that Debian should continue to support just as we do our other ports that (until recently) weren't in any shape to release. > and debian-installer, eg. I was told that all the people wanting to work on debian-installer got hijacked into doing boot-floppies work. :) Furthermore, I can't think of *anyone* who's been wheedling, cajoling, and hounding people to pay attention to boot-floppies Or Else We'll Never Release. :) Debian has a tremendous amount of resources compared to some software shops, but our resources aren't infinite. Sometimes we allocate away from one project in favor of another. > What, if anything, can or should be done to ensure these things > actually get finished and released? All I think we need do is refuse to shut the door on them. We need to leave people free to gravitate towards the projects that interest them, because, as 2.1.1 reminds us, we can't force them. > Do you think Debian should continue to support the LSB? Yes. > If so, what do you plan on doing to ensure issues like the bin uid and > filetype detection are resolved satisfactorily? Well, I think we could antagonize the current LSB staff a little less. I don't think we've reached the point where it's necessary to claim the LSB a failure. Far from it. I think we should try working from the inside for a while. If we need an official delegate to the LSB, I'd be happy to appoint one. (Though, I thought we already had one -- wasn't it Dale Scheetz?) > Should Debian (or SPI) be involved in distributing data (as opposed to > programs) that can be distributed, and might be useful for Debian users, > eg the RFCs, the Bible, books from Project Gutenburg, desktop theme > packages, or game data files? I believe we should, as long as that data is licensed in a way that is consistent with the DFSG. We approved the creation of a "data" section long ago for this purpose. However, that fact that it continues to be unavailable suggests to me that some people may be uncomfortable with that decision. > Is there anything that Debian (or SPI) can or should be doing (either > in the next twelve months or longer term) to promote more open media > formats? I've always been a fan of grass-roots efforts. Use OGG files, not MP3s. Report bugs (politely) when you find them. Do work on these projects. Help give them the vitality they need, in the hopes that they'll reach critical mass and explode onto the marketplace. It's not like the deck is stacked against them (unless the CBDTPA, neé SSSCA passes). People would always rather NOT pay licensing fees than pay them. > Is there anything that Debian can or should be doing (either in the next > twelve months or longer term) to make SPI more useful? Ordinary SPI members, and Debian Developers, can hold Board members accountable when they don't show up to Board meetings. Now, I'm not going to name any names... > What directory should traceroute be in? /usr/bin, of course. And, thankfully, cooler heads have recently prevailed. > What's more important: being as open as possible about things, > getting them done in a timely manner, or avoiding making a decision on > controversial topics? I'd have to rank openness at the top. > Will you be at the next linux.conf.au in Perth, January 2003? It sounds interesting. If so I'd better start thinking about getting my passport soon. Is the site wheelchair-accessible? I could hardly go and leave my wife behind. :) > Do you think any of these questions were biassed or prejudicial? No more so than most mails I see on Debian lists. :) > If so, don't you think you're being a bit overly sensitive for a > pompous blowhard? Wait, don't I get to be an overly sensitive, pompous blowhard even if I *didn't* think the questions were biased or prejudicial? :) -- G. Branden Robinson | Damnit, we're all going to die; Debian GNU/Linux | let's die doing something *useful*! branden@debian.org | -- Hal Clement, on comments that http://people.debian.org/~branden/ | space exploration is dangerous
Attachment:
pgpAzkOa7JIjR.pgp
Description: PGP signature