Re: Some questions for the candidates...
aj@azure.humbug.org.au (Anthony Towns) writes:
> So. The first question is is this dissatisfaction justified? How long is
> the woody release taking compared to other releases?
That's an interesting way to look at it, but frankly I'm more interested in
how our users feel about it ... and it seems clear to me that they would like
us to be more predictable, and more frequent, with our releases.
> ... but at the very least it seems unlikely there'll be any transitions
> on quite the same scale for a while.
Exactly. As you yourself said to me in Brisbane, the real proof of the
utility of pools and testing is not the woody release, but the release after
woody. If the tools and processes we have put in place make it easier to
get the next release out, woody will have been worth waiting for. I'm pretty
optimistic about that, but only time will tell.
> Or, at least, that's my theory. The candidates may have other ideas. If
> so, that may just mean we'll have to bring the release slightly forward
> to make sure they don't have a chance to implement them. Muahaha.
Little would please me more than for woody to release during Ben's remaining
term in office. :-)
> What do you consider the DPL's field?
There are fundamental qualities of leadership that I think we should always
expect in our leader. But we have had very different DPL's, and I think each
one has brought something to the project.
Personally, of the items on your list, I'd probably pick "technical
leadership" as the thing I'm most likely to excel at. I suspect from his
responses that Raphael and I have different definitions of what technical
leadership means, though. There is a definition based on leading by doing
which describes me fairly well, and which clearly was a good description of
how our first two project leaders succeeded.
But our project has grown, and grown significantly. That definition of
technical leadership isn't sufficient any more. What is required now, and
what I think I can provide, is the ability to recognize good ideas, pick the
ones that align well with and support our long term vision... then take steps
to foster them, promote them, and recognize accomplishments when they happen.
> As DPL, how will you ensure the technical goals in your platform are
> achieved?
Leverage.
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.
> Personally, I often find it difficult to get people to work ...
Absolutely. Not everyone is interested in working on important but unglamorous
things. All we can do is keep trying.
> To be more concrete: Bdale, how will you ensure that "the benefits
> of implementing caching proxy servers instead of mirrors" and
> so forth are actually available to our users instead of just
> talked about?
I'm thinking a HowTo document would be a good next step. The hard part is the
communication plan to get the word out and convince people it's an idea worth
pursuing. The visibility that goes with serving as DPL could help that.
> 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've been more or less quietly making things happen for Debian since 1995,
and I'm not about to stop now.
> 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]
I think BenC did a good job of helping get the crypto-in-US-main process
kicked off, but as he has himself indicated I don't think he did much to prod
it along after that. I suspect I would have taken a somewhat more active role
were I DPL, since I think that was an important issue. All the other things
relating to trying to get woody released that I thought about doing, I
actually did...
> How well or poorly do you think we've gone at _avoiding_ problems due
> to each of the following? Same qualifications.
>
> 5. Bandwidth consumed by our distribution methods [Bdale]
I think we've mostly dodged the issue by continuing to acquire enough donated
resources to make things work regardless of how beefy our requirements are.
> 6. The number of packages in the distribution [Bdale]
> 7. The administration effort required to keep the project
> running [Bdale]
The work on tools like new incoming in recent months has probably helped keep
these manageable. But with both the source package count and maintainer count
still apparently growing more or less linearly with time, I think we still
should be concerned about both of these as ongoing issues.
> 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?
I think wrestling the crypto-in-US-main effort through to the point where we
are just a few procedural steps away from completing the implementation is a
major accomplishment in the last year. The buildd.debian.org interface to
autobuilder logs that Ryan Murray put up based on work Chris Rutter started
was the neatest new thing for making it easier to maintain Debian packages
in the last year. I'm also impressed at the number of ports that we now have
in more or less viable and releasable state... the number of bugs filed and
resolved on porting-related issues in the last year certainly must have set
some sort of record!
I'm having a hard time pointing to any particularly big problems we have faced
in the last year. It feels as though there has been a fairly steady stream
of the same little things we more or less always have to deal with...
> Top three things you hope Debian will achieve during the next twelve
> months?
Complete the crypto-in US main transition, release woody, and elect me DPL...
hopefully in that time order... :-)
> Top three problems you think Debian will face during the same
> period? 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?
My platform states fairly clearly, I think, what longer term goals and concerns
I have. It's hard for me to pick out problems that I think might be more or
less important in the next year versus later.
> 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 ?
Actually, if it is remaining relatively linear in a period where the number of
source packages also continues to grow fairly linearly, I'm not sure we need
to panic about the fact that the number of open bugs is growing per se. As I
indicated in my platform, I think it's vitally important that we continue to
work hard on improving Debian's quality... so you can expect to hear more from
me about various quality metrics than we have from Ben if I am elected.
> There are many purely technical subprojects within Debian that would
> be useful if completed ... What, if anything, can or should be done to
> ensure these things actually get finished and released?
As mentioned in my platform, I think we can and should be able to articulate
a "roadmap" of features and such that we are working on, and set tentative
goals about which things we might want to get done before each planned release.
That won't magically get the work done, but giving more visibility to some of
these subprojects and how they might help us achieve our long-term goals is
clearly something the DPL and and should do.
> Do you think Debian should continue to support the LSB? If so, what do you
> plan on doing to ensure issues like the bin uid and filetype detection are
> resolved satisfactorily? If not, what, if anything, should we do instead?
Yes, as I have already stated, I think Debian should support the LSB. I think
we are actively engaging to resolve the issues, and should continue to do so.
> 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 don't have any philosophical problem with Debian or SPI distributing data,
but I'm concerned about the practical impact on our infrastructure,
particularly our mirror network.
> 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 don't have any new ideas here.
> Is there anything that Debian can or should be doing (either in the next
> twelve months or longer term) to make SPI more useful?
I'm quite pleased to see SPI stirring. Branden seems to be doing a good job
of pulling the books back together... and I hope they stay together!
SPI has the potential to do much more good than it has to date, but I'm not
convinced that there's much Debian per se can or should be doing to prod SPI
along... other than to insist that those things SPI does on behalf of Debian,
like keep our financial records, are done well.
> What directory should traceroute be in?
I personally think /sbin and /usr/sbin belong in PATH. Probably means I've
been a sys admin for too many years, or something. :-) Given that, I don't
care much which directory traceroute is in, as long as it's in my path...
> 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'm not sure I see the first two as being in conflict, and both are important.
> Will you be at the next linux.conf.au in Perth, January 2003?
I certainly hope so! :-)
> Do you think any of these questions were biassed or prejudicial?
No more so than I would expect from someone who spends as many hours as you do
working on and thinking about Debian. :-)
> ``Debian: giving you the power to shoot yourself in each
> toe individually.'' -- with kudos to Greg Lehey
"Debian: everything looks broken until you realize it's just the only distro
done correctly..." -- Dann Frazier
Bdale
Reply to: