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
Loading Image...
?
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.
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*!
***@debian.org | -- Hal Clement, on comments that
http://people.debian.org/~branden/ | space exploration is dangerous
