Discussion:
Some questions for the candidates...
(too old to reply)
Scott Dier
2002-03-15 06:07:02 UTC
Permalink
http://www.google.com/search?q=cache:5U4Nl71NoMEC:www.geocrawler.com/archives/3/216/1998/5/100/1143489/++site:www.geocrawler.com+%22debian+development+modem%22+bdale&hl=en
With context!

http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=199805300704.BAA08336%40chunks.gag.com&rnum=1&prev=/groups%3Fq%3Dg:thl2976599177d%26hl%3Den%26ie%3DISO-8859-1%26oe%3DISO-8859-1%26selm%3D199805300704.BAA08336%2540chunks.gag.com
--
Scott Dier <***@ringworld.org> http://www.ringworld.org/
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Anthony Towns
2002-03-21 10:11:11 UTC
Permalink
Some questions for the DPL candidates...
$ date
Thu Mar 21 20:11:00 EST 2002

So, a followup question for Branden: does your lack of response to these
questions reflect the level of accountability and responsiveness we can
expect from you if elected?

(Or, alternately, "just reply already, geez")

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Branden Robinson
2002-03-21 18:06:34 UTC
Permalink
Post by Anthony Towns
Some questions for the DPL candidates...
$ date
Thu Mar 21 20:11:00 EST 2002
So, a followup question for Branden: does your lack of response to these
questions reflect the level of accountability and responsiveness we can
expect from you if elected?
A sample size of one makes for poor statistical analysis. I suggest you
take a look at the other messages I've posted to this list:

Feb 26 Cc debian-***@lists ( 35) Declaring Intent to run for Debian Project Leader
Feb 27 To debian-***@lists ( 54) Re: Opinions on crypto-in-main
Mar 01 To debian-***@lists ( 117) Re: debian services and responsibility
Mar 01 Cc debian-***@lists ( 43) Re: debian services and responsibility
Mar 01 To debian-***@lists ( 162) Re: debian services and responsibility
Mar 01 Cc debian-***@lists ( 66) Re: debian services and responsibility
Mar 01 Cc debian-***@lists ( 153) Re: debian services and responsibility
Mar 01 Cc debian-***@lists ( 115) Re: debian services and responsibility
Mar 01 To debian-***@lists ( 47) Re: debian services and responsibility
Mar 03 To debian-***@lists ( 79) Re: Can SPI treasurer and DPL be done by the same person?
Mar 03 To debian-***@lists ( 141) Re: Questions for the candidates
Mar 03 To debian-***@lists ( 457) Branden Robinson's Platform for Debian Project Leader -- 2002
Mar 04 To debian-***@lists ( 102) Re: Question restated
Mar 04 To debian-***@lists ( 44) Re: Question to Candidates
Mar 04 To debian-***@lists ( 138) Re: Questions to Candidates
Mar 04 To debian-***@lists ( 64) Re: 3 questions
Mar 05 To debian-***@lists ( 71) Re: responsability, blah blah blah
Mar 05 To debian-***@lists ( 40) Re: 3 questions
Mar 05 To debian-***@lists ( 190) Re: Question restated
Mar 06 To debian-***@lists ( 143) Re: Questions for the candidates
Mar 06 To debian-***@lists ( 61) Re: Q to all 3: DPL appointed positions
Mar 08 To debian-***@lists ( 592) diplomacy, courtesy, and all that good stuff
Mar 08 To debian-***@lists ( 51) Re: diplomacy, courtesy, and all that good stuff
Mar 08 To debian-***@lists ( 44) Re: diplomacy, courtesy, and all that good stuff
Mar 08 To debian-***@lists ( 39) Re: diplomacy, courtesy, and all that good stuff
Mar 09 Cc debian-***@lists ( 47) Re: Debate announcement and call for votes
Mar 09 To debian-***@lists ( 42) Re: Debate announcement and call for votes
Mar 11 To debian-***@lists ( 42) Re: diplomacy, courtesy, and all that good stuff
Mar 14 To debian-***@lists ( 51) Re: Rebuttals appended to candidate platforms
Mar 14 Cc debian-***@lists ( 650) Re: Rebuttals appended to candidate platforms
Mar 15 To debian-***@lists ( 93) Re: questions: programming and leadership experience
Mar 15 To Debian Vote Discu ( 75) Re: Q for candidates: the ALS issue
Mar 15 To debian-***@lists ( 52) Re: Debian GNU/Hurd and Debian GNU/*BSD
Mar 15 To Debian Vote ( 76) Re: Question regarding Raphael's platform
Mar 18 To debian-***@lists ( 64) Re: question for all: Content of packages
Mar 19 Cc debian-***@lists ( 51) Re: Debian GNU/Hurd and Debian GNU/*BSD
Mar 20 Cc debian-***@lists ( 63) Re: Debian GNU/Hurd and Debian GNU/*BSD

Is your selective disregard of empirical data something I can expect to reflect
in your work as a DPL delegate? :)
Post by Anthony Towns
(Or, alternately, "just reply already, geez")
Your message was very long and challenging to answer with the kind of attention
I'd like to give it. It's my intent to have it answered before the debate.

There are also two other alternatives:

1) You can break your flurry of questions down into a set of mails, each
centered around a given topic (admittedly, it's a bit late for that); or
2) We could use a metric for candidate assessment that doesn't include being
able to rise to arbitrary challenges leveled by arbitrary developers; this
isn't a weight-lifting contest. Or if it is, I challenge my fellow
candidates to prove that P = NP, or formulate a comprehensive and
testable theory of quantum gravitation, and we can all acknowledge our
inadequacy. :)

Nevertheless it's still my intent to reply. I'm sorry if the response is not
as rapid as you'd like; I've had to prioritize several things more highly than
your message. I hope you'll understand if I don't regard getting involved in
very long email discussions as the primary function of a Project Leader, though
it may be required in furtherance of some end more directly related to his or
her duties.
--
G. Branden Robinson | The errors of great men are
Debian GNU/Linux | venerable because they are more
***@debian.org | fruitful than the truths of little
http://people.debian.org/~branden/ | men. -- Friedrich Nietzsche
Anthony Towns
2002-03-22 05:04:44 UTC
Permalink
Post by Branden Robinson
Post by Anthony Towns
Some questions for the DPL candidates...
So, a followup question for Branden: does your lack of response to these
questions reflect the level of accountability and responsiveness we can
expect from you if elected?
A sample size of one makes for poor statistical analysis. I suggest you
Which seems to indicate you've had plenty of time to reply to questions.
Post by Branden Robinson
1) You can break your flurry of questions down into a set of mails, each
centered around a given topic (admittedly, it's a bit late for that)
Or you could take the initiative and just reply to parts of it in separate
mails if that's more suitable for you.
Post by Branden Robinson
2) We could use a metric for candidate assessment that doesn't include being
able to rise to arbitrary challenges leveled by arbitrary developers
Or you could try not misinterpreting a bunch of questions sent to all
the candidates as some sort of offensive, and just reply to them. Both
the other candidates managed to do so fairly quickly. And I suspect,
somehow, that there's more than just an "arbitrary" developer who's
interested in your responses.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Branden Robinson
2002-03-23 06:29:06 UTC
Permalink
And I suspect, somehow, that there's more than just an "arbitrary"
developer who's interested in your responses.
...which is why it's my intent to reply.
--
G. Branden Robinson | "There is no gravity in space."
Debian GNU/Linux | "Then how could astronauts walk
***@debian.org | around on the Moon?"
http://people.debian.org/~branden/ | "Because they wore heavy boots."
Branden Robinson
2002-03-23 19:08:44 UTC
Permalink
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
Wichert Akkerman
2002-03-24 12:30:55 UTC
Permalink
Post by Branden Robinson
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.
And as security team we'ld like to get some better support from DSA
and buildd maintainer so we don't have to wait as long on build
dependencies to be installed and rbuilders to appear (after a few months
of asking around we are still at exactly 1 working rbuilder in
debian.org..). I'm not quite sure how a DPL can help in that though.
Post by Branden Robinson
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".
Endorsement by Oracle is solely a matter of money: someone will have
to spent a nice amount of cash to get woody certified by Oracle. The
procedure isn't all that difficult.

Wichert.
--
_________________________________________________________________
/***@wiggy.net This space intentionally left occupied \
| ***@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Branden Robinson
2002-03-24 20:56:52 UTC
Permalink
Post by Wichert Akkerman
Post by Branden Robinson
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.
And as security team we'ld like to get some better support from DSA
and buildd maintainer so we don't have to wait as long on build
dependencies to be installed and rbuilders to appear (after a few months
of asking around we are still at exactly 1 working rbuilder in
debian.org..). I'm not quite sure how a DPL can help in that though.
I'm open to suggestions, as I am sure the other candidates are.
Post by Wichert Akkerman
Post by Branden Robinson
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".
Endorsement by Oracle is solely a matter of money: someone will have
to spent a nice amount of cash to get woody certified by Oracle. The
procedure isn't all that difficult.
How much are we talking about? I'm always in the mood to try organizing
a fundraiser. Since I suspect you're talking about way more than
$1,000, which we raised pretty quickly for Debian's OASIS membership, we
might need to find companies that would be willing to participate.
--
G. Branden Robinson | You can have my PGP passphrase when
Debian GNU/Linux | you pry it from my cold, dead
***@debian.org | brain.
http://people.debian.org/~branden/ | -- Adam Thornton
Anthony Towns
2002-03-25 19:05:53 UTC
Permalink
I just wanted to followup on one issue. I'll start with Raphael's answer
What do you consider the DPL's field?
- technical leadership?
Not really, we are quite good a taking technical decisions (the leader
can participate of course but he's not more influencial than any other
developer). And we already have the technical committee to resolve
the controversial issues.
I think it seems pretty strange to say that "the Debian Project _Leader_"
isn't any more influential than others when it comes to leadership on
technical issues. (It seems especially strange coming from someone whose
platform consists of a whole raft of new, technical, goals for Debian
to work on over the next twelve months and beyond, but hey)

I was a little surprised to notice the other day [0] that even way back
in the day, the constitution took something like this into account, saying:

] 5. Project Leader
] 5.1. Powers
] The Project Leader may:
] 9. Lead discussions amongst Developers.
] The Project Leader should attempt to participate in discussions
] amongst the Developers in a helpful way which seeks to bring the
] discussion to bear on the key issues at hand. The Project Leader
] should not use the Leadership position to promote their own
] personal views.

[0] "when I was skimming the constitution, as you do"...
As DPL, how will you ensure the technical goals in your platform are
achieved?
Leverage.
(Surely I'm not the only one that immediately thought of blackmail when
Bdale wrote that?)
It's clear to me that serving as DPL, and taking on the additional tasks
that go with the territory, will leave me less personal technical time than
I have today. I have learned in my professional life that I can derive as
much satisfaction from the accomplishments of others that I am helping lead
as I can from personal technical achievement, so I feel well equipped to
cope with that same transition in my Debian activities if I am elected.
The key to getting my goals accomplished will be doing a good enough job
explaining my ideas and showing how they align with our long-term vision,
that others are motivated to go out and do the work required to make them
happen.
I'm sure I'm not disagreeing with Bdale when I say this, but the other
half of this is getting people to... properly focus their ideas, might
be one way of putting it. A lot of... energy, or time, or, at the very
least bandwidth seems to be being spent by people working out how to
solve their problems, which is great, but it never actually gets anywhere
because they completely forget about everyone else who has an interest
in the matter.

There's a lot to be said, in my opinion, for having someone get in amongst
the people with the clever ideas and to bang their heads against all the
issues they're conveniently ignoring until they actually manage to come
up with something practical.

To take a fairly trivial example from -devel right now: people have been
going on and on about wanting to make Packages files easier to download
for ages now, and the threads take the exact same path each time:
"let's split them", "oh wait, that doesn't work properly", "let's make
them incremental", "well, why not use rsync", "no, let's rearrange the
archive" and we end up without any consensus, nor anything that works
with existing tools, nor an actual fix for the problem.

IMO, having someone with some credibility actually help the people who're
interested in these sorts of things work out a credible solution would be
helpful. To stick with the Bdale-centrism of this section, perhaps the
solution to the above problem isn't to change the Packages file at all,
or the way *apt* downloads stuff, but to encourage modem users to run a
specialised local proxy similar to that suggested in Bdale's platform,
and have some separate mirror network that includes a few days of diff's
that they can use to recreate a full Packages file. But it's hard to
know what sort of things you need to be thinking about when you're just
not aware of all the things you need to take into consideration, and,
with the size and popularity and scope of Debian these days, it's _hard_
to know all those things.
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.
This'll serve as another example, I think. There's a whole raft of
unanswered questions with `a data section' (the bug is #38902, for
reference). Some are: does it make sense to use normal Debian packages
for data? Does all the Depends: and Conflicts: stuff really make sense,
or the preinst and postrm stuff? Is there such a thing as arcitecture
specific data? Is there even any point separating the source from the
packages, or should we just distribute the source and auto-generate
whatever formats are needed? If we get rid of all that, and use some other
packaging format, will that make it possible for users to install these
packages rather than just admins, and is that useful? If it's packaged
differently, will that make it installable on other Linux distributions,
or on non-Linux Unices, or even on Windows? What sort of licenses should
we accept? Is the DFSG the appropriate thing to use, or should we look
at the usual licenses used for data (which often have "non-modifiability"
as a key feature), and apply a different standard? What should we accept,
exactly? Just stuff that adds on to our distro, like game levels? How
about pretty pictures of naked girls that make good backgrounds? How about
guitar riffs someone thought was cool and wanted to upload? Or how about
100s of MBs of geological data in various levels of detail? How does this
work with or against things like themes.org or Prject Gutenburg? Do we
consider them co-projects, or upstream? If we start getting everything
on them, and who knows how much else, can our servers handle it? Can our
mirror network handle it? Should our mirror network handle it, or should
data be mirrored independently from the Debian operating system? Should
Debian even be doing it?

None of these questions have really been resolved particularly
well. Alternatives haven't been thought out, we've just said "oh, yeah,
as far as we're concerned, we can just add a new section like `contrib',
and stick it there". Given some of the different responses by the DPL
candidates to the above question, it seems pretty obvious that we don't
actually have any real consensus, even on the fundamentals.

It's not clear how we're going to resolve such things, or even if we are.
Debian's pretty proficient at letting difficult, unimportant things
just slide into irrelevancy, and that's probably a good thing. It's not
a good thing to get highly intelligent and motivated people donating
their time for free, then wasting it on things that don't actually turn
out to matter. Quicker "apt-get update"s and having somewhere to upload
data might be those sorts of things.

On the other hand, maybe it'd be helpful to have whoever's elected as
DPL (not to mention the RM, or people from QA, or policy writers, or
random developers) take a more active roll in actually resolving all the
difficult and unstated issues as well as the obvious and straightforward
ones.

To give another example: at the start of 2001, crypto-in-main was pretty
much at the same point as "the data section" still is: some people had
"decided" to their satisfaction that was all ready to go, but some fairly
serious issues (whether it's actually legal for Debian to do, how the
notifications were to be handled) hadn't been remotely addressed. Until
they had been addressed, it didn't go anywhere. (81852 is the bug number
this time) This might serve as a particularly good example, in that
it was our glorious DPL who stepped in and got us rolling on actually
getting legal advice that wasn't accompanied by an "IANAL".

(Or maybe this is all nonsense. Maybe this is how the fashion of DPLs
works. We want interventionist DPLs one year, then we get one and get sick
of them intervening and want them to shut up for a while, then we forget
and start over. Something seems weirdly different about all this compared
to how elections have gone in the past, anyway. Who knows? Not me)

There aren't any real questions for the candidates here, just comments,
so certain people who're overly busy needn't feel compelled to reply. ;)

Cheers,
aj, wondering if he managed to finish this before the CFV's has gone out,
and thus can at least argue to still be within the `campaigning'
period
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Bdale Garbee
2002-03-25 21:01:52 UTC
Permalink
Post by Anthony Towns
As DPL, how will you ensure the technical goals in your platform are
achieved?
Leverage.
(Surely I'm not the only one that immediately thought of blackmail when
Bdale wrote that?)
Hehe. Actually, that's not what I was thinking about... I had in mind the
physical idea of a lever, where a small amount of pressure applied in the
right place can make significant things happen at the other end. I think a
big part of a leader's job is to try and identify those activities where
lending a little support can make something good happen faster or better
than it would otherwise.
Post by Anthony Towns
The key to getting my goals accomplished will be doing a good enough job
explaining my ideas and showing how they align with our long-term vision,
that others are motivated to go out and do the work required to make them
happen.
There's a lot to be said, in my opinion, for having someone get in amongst
the people with the clever ideas and to bang their heads against all the
issues they're conveniently ignoring until they actually manage to come
up with something practical.
Section 5.1.9 in our constitution addresses this directly, by encouraging the
DPL to lead discussions towards key issues. Your idea is one of the things I
was thinking about when I said in my platform that "The primary role of the
leader is facilitation, which comes in many forms." I'm very good at clearly
and directly articulating what seem to me to be the key ideas in a discussion,
which is often all it takes...

Bdale
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jules Bean
2002-03-25 23:19:40 UTC
Permalink
Post by Anthony Towns
To take a fairly trivial example from -devel right now: people have been
going on and on about wanting to make Packages files easier to download
"let's split them", "oh wait, that doesn't work properly", "let's make
them incremental", "well, why not use rsync", "no, let's rearrange the
archive" and we end up without any consensus, nor anything that works
with existing tools, nor an actual fix for the problem.
Actually, that one was solved, by Ben Bell. He set up the scripts to
calculate teh diffs, do the md5sum checks for consistency, download,
apply etc.

I don't know if anyone apart from him and me use it, though. Maybe
that's another problem...

Jules
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gustavo Noronha Silva
2002-03-26 00:34:21 UTC
Permalink
On Mon, 25 Mar 2002 23:19:40 +0000
Post by Jules Bean
Post by Anthony Towns
To take a fairly trivial example from -devel right now: people have been
going on and on about wanting to make Packages files easier to download
"let's split them", "oh wait, that doesn't work properly", "let's make
them incremental", "well, why not use rsync", "no, let's rearrange the
archive" and we end up without any consensus, nor anything that works
with existing tools, nor an actual fix for the problem.
Actually, that one was solved, by Ben Bell. He set up the scripts to
calculate teh diffs, do the md5sum checks for consistency, download,
apply etc.
if that's not an official solution, that'll be integrated in apt or on
the server side, that's not solved... a shell script to create diffs
on people.debian.org/~kov and bring them to my machine is easy to create,
but that's not useful at all for the project

[]s!
--
***@debian.org: Gustavo Noronha <http://www.metainfo.org/kov>
Debian: <http://www.debian.org> * <http://debian-br.cipsga.org.br>
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jules Bean
2002-03-26 11:51:49 UTC
Permalink
Post by Gustavo Noronha Silva
On Mon, 25 Mar 2002 23:19:40 +0000
Post by Jules Bean
Post by Anthony Towns
To take a fairly trivial example from -devel right now: people have been
going on and on about wanting to make Packages files easier to download
"let's split them", "oh wait, that doesn't work properly", "let's make
them incremental", "well, why not use rsync", "no, let's rearrange the
archive" and we end up without any consensus, nor anything that works
with existing tools, nor an actual fix for the problem.
Actually, that one was solved, by Ben Bell. He set up the scripts to
calculate teh diffs, do the md5sum checks for consistency, download,
apply etc.
if that's not an official solution, that'll be integrated in apt or on
the server side, that's not solved... a shell script to create diffs
on people.debian.org/~kov and bring them to my machine is easy to create,
but that's not useful at all for the project
This answer is not directed at Gustavo. My use of the second person is
intended to be impersonal!

You can't have it both ways! The standard Debian answer to a good
idea is 'show us the code'. Well, in this case, the code was written
and demonstrated. It would obviously not be difficult to integrate it
with the tools available if we wanted to; perhaps we don't. But the
code has been written as proof of concept. And it is a significant
time saving for people with slow links who like to update their
Packages files frequently.

Jules
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Gustavo Noronha Silva
2002-03-26 18:07:20 UTC
Permalink
On Tue, 26 Mar 2002 11:51:49 +0000
Post by Jules Bean
Post by Gustavo Noronha Silva
if that's not an official solution, that'll be integrated in apt or on
the server side, that's not solved... a shell script to create diffs
on people.debian.org/~kov and bring them to my machine is easy to create,
but that's not useful at all for the project
This answer is not directed at Gustavo. My use of the second person is
intended to be impersonal!
it's ok, I don't get discussions personally =D
Post by Jules Bean
You can't have it both ways! The standard Debian answer to a good
idea is 'show us the code'. Well, in this case, the code was written
and demonstrated. It would obviously not be difficult to integrate it
with the tools available if we wanted to; perhaps we don't. But the
well, if has been written and works well enough that our servers and/or
tools may "merge" it, why not file a bug on them?
Post by Jules Bean
code has been written as proof of concept. And it is a significant
time saving for people with slow links who like to update their
Packages files frequently.
ok, I would like to test this, Show us the code (TM) =D

[]s!
--
***@debian.org: Gustavo Noronha <http://www.metainfo.org/kov>
Debian: <http://www.debian.org> * <http://debian-br.cipsga.org.br>
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jules Bean
2002-03-27 09:16:54 UTC
Permalink
Post by Gustavo Noronha Silva
Post by Jules Bean
You can't have it both ways! The standard Debian answer to a good
idea is 'show us the code'. Well, in this case, the code was written
and demonstrated. It would obviously not be difficult to integrate it
with the tools available if we wanted to; perhaps we don't. But the
well, if has been written and works well enough that our servers and/or
tools may "merge" it, why not file a bug on them?
People didn't seem interested in it.
Post by Gustavo Noronha Silva
Post by Jules Bean
code has been written as proof of concept. And it is a significant
time saving for people with slow links who like to update their
Packages files frequently.
ok, I would like to test this, Show us the code (TM) =D
http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg01303.html

Jules
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Raphael Hertzog
2002-03-26 00:38:14 UTC
Permalink
Post by Anthony Towns
I just wanted to followup on one issue. I'll start with Raphael's answer
I'll try to be more clear then ...
Post by Anthony Towns
can participate of course but he's not more influencial than any other
developer). And we already have the technical committee to resolve
the controversial issues.
I think it seems pretty strange to say that "the Debian Project _Leader_"
isn't any more influential than others when it comes to leadership on
technical issues.
It depends on what kind of leadership you wish ... when a subject
matters to me, I participate and give arguments and so on. I should
not have more "power" to impose my personal views on any technical
decision.

However, when I'm not directly involved in a discussion, when I just
follow it, and if the discussions seems to go nowhere, I may jump in
to remind what the goals are and to focus the discussion again on
something that is useful to Debian. I may also let it die if I think
that nothing interesting can come out of it.

It's surely not easy to distinguish both cases but that's my
interpretation of the constitusion 5.1.9 as you quote it. And I do
agree with that part of the constitution.

Even if (in the facts) the leader is more influential than the other
developers when it comes to technical decisions, I don't think it's in
his scope to participate in all the technical decisions, he has already
enough to do with the rest (infrastructure and internal/external
communication).
Post by Anthony Towns
(It seems especially strange coming from someone whose
platform consists of a whole raft of new, technical, goals for Debian
to work on over the next twelve months and beyond, but hey)
Well, my platform doesn't consist of "technical goals". My platform is
about "tools" to let us realize Debian's goals. Of course, the setup
of those tools can be considered like a little goal on our path ... :-)

Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Continue reading on narkive:
Loading...