Re: Questions for Bdale
email@example.com (Raphael Hertzog) writes:
> First of all, you give 2 or 3 "areas of focus", but what is that
> exactly ?
> A set of tasks that you'd like to highlight in the hope that more
> people will work on them ?
That's pretty close.
One of the roles of a leader is to help identify areas where additional
attention or effort would help to advance our vision. Sometimes, a quiet
suggestion or some encouragement to a person already working on something
is enough. Sometimes broader attention by the project is required for a
change to be successful, and I believe these three areas are all in this
> Concerning the "flavors": even if it has not explicitely been said, with
> the growing numbers of "subprojects" it's self-evident that the notion
> of flavor is gaining momentum ... I suppose that you want to push that
> even more ? I'm with you, that's good for Debian.
When I mentioned the concept of flavors of Debian during my recent trip to
Linux Conf Australia, the idea captured people's imagination much more than
it has in the past. This is partly because of the recent emergence of
subprojects... but I also had strongly positive reactions for other reasons.
Some people were worried about the sheer size of Debian overwhelming new users,
and see flavors as a way to address that. Others are working on automating
installations for specific server and/or thin-client applications, and see
flavors as a way to describe what they're doing and make it available to
others easily. Giving flavors a name, and talking about the idea in the
context of advancing our vision for Debian's future, is part of what I think
I can and should do as DPL.
As the Debian project has grown and evolved, the early idea we had that Debian
might be a base others build application-specific derived distributions on
changed to one of Debian growing to encompass all the people, packages, and
activities required to meet the needs of many application areas. I believe
adding explicit support for flavors to our thinking and our infrastructure
is a logical step in our evolution.
> But do you have some specific plans, ideas ?
My platform is the first time I've given the concept of explicit support for
flavors broad visibility. Anthony Towns indicated that he would investigate
adding support for flavors to our archive management tools. Everyone I have
talked to about the idea so far is enthusiastic about it, and so I'm hopeful
that we can actually deliver a couple of flavors as part of our next stable
> Same question for the two other "areas of focus", do you have specific
> ideas or plans ?
I think I was fairly explicit about my goals for internationalization. I've
talked on IRC with some of the people working on debian-installer, and they
already intend to deliver improved support for native language installations.
My goal in putting this in my platform is to help everyone see this as
something I believe is important for the project as a whole.
In the area of community, I expect to continue to try and meet more Debian
developers, and to help promote events that bring members of the Debian
community together. I have a number of ideas for improving communication
that aren't fully formed yet, ranging from trying to lead by example with
some sort of web log of the things I'm working on as leader that aren't worthy
of some huge announcement, to asking for more explicit reports from teams and
delegates within the project whose activities aren't well understood.
> Concerning the last year, how do you feel about the way you managed
> internal dissensions ? DAM and the NM is the most critical example that
> comes to my mind but I'm sure you have worked on several other problems.
I don't know that we had many "internal dissensions", but I certainly had a
number of issues brought to my attention during the past year! In each case,
the first step was to exercise "due diligence" by investigating what was
Often, the problem was solved by pointing to documentation, forwarding to
the right place to get help, or helping decipher what someone else had said
that seemed confusing without sufficient context. In the cases where there
seemed to be a real problem, I contacted the person or group responsible,
communicated the issue, and worked with them to identify solutions. While I
always attempted to follow up with whoever reported the initial issue, my
preference is generally to ask the person or group responsible for a process
to communicate what they did to the project at large. I think it's best
for the project overall if the people actually doing the work report on it
and get credit for their accomplishments directly.
You mention the NM process specifically, and it was indeed one of the ones I
investigated. There have been persistent concerns expressed about how well
it works, most of which result from how some individual applicant was handled.
I served briefly as an AM after the current process was put in place, and so
I had at least a start on understanding how the process works and where there
might be problems. Frankly, since there are human elements involved in this
process, I'm not sure we will ever have an NM process that makes everyone
happy all the time. I look once in a while at the overall growth in the
number of registered developers, because it is an interesting graph to include
in public talks. From that, my general sense was that our NM process was
"working", because the number of registered developers continues to increase
However, after talking to our DAM James Troup about it, talking to several
of our AMs, hearing directly from a couple applicants who felt "stuck" in the
process, and looking at the responses to a request for status reports that I
sent to everyone on our "organization" page at the start of January...
there are two things that clearly continue to be issues with the NM process.
The first is time, both how long it can take to complete the overall process
and the fact that certain applications seem to take much longer than others.
The second actually derives from the first, and is that applicants that take
longer to process than others don't get much feedback about why there is a
There seems to be some confusion in the public discussion about the NM process
around what needs to happen after the AM completes their report. While I
don't know all the details, it is clear that the DAM is expected to exercise
judgment, and his role is *not* a purely automatic one after an AM completes
their report. I'm pleased that James appears to be working through the set of
applicants with very long hold times in the NM queue. Since those applicants
are the ones about which we have had the greatest public concern, if he gets
caught up on those the majority of the current problem may be solved.
I continue to have many conversations about what we could do to make further
improvements in the NM process, and there are no easy answers. People are
people, and everyone from applicants to the DAM get distracted by other tasks
from time to time. Clearly, the DPL needs to keep an eye on critical processes
like NM, and I certainly will continue to do so if re-elected. Anyone who
would like to help the NM process should talk to the "front desk" about
becoming an AM, as that is probably the fastest way to learn how the current
process works and make a difference for the future.
> Do you think you have been good at communicating with the other Debian
> developers ? If no, what do you plan to change to do better next year ?
Overall, I think I've done a pretty good job communicating with other Debian
developers both publicly and privately.
I used debian-devel-announce when I thought that was appropriate, pointed
things out to our DWN editors and press contacts when that seemed like a
better approach, and joined discussions in various working groups around
the project when I had something to contribute.
I am routinely approached by individual developers on IRC and via email with
all sorts of questions, ranging from packaging and porting problems to how
they can gain support for some new idea or project... and I spend a lot of
time answering those sorts of questions because I think that's important to
There is, however, a class of information that is just hard to communicate
effectively, where I don't think I've done any worse than any previous DPL
but am still not satisfied myself. I get involved in a lot of "little
activities" as DPL that aren't worthy of some big report by themselves, but
would be good for developers in general to hear about somehow. That's why I
mentioned the web log idea earlier. Writing a diary isn't something that
comes naturally to me, but it may turn out to be the best way to make visible
some of the activities I engage in as DPL.
> Will HP continue to pay the travels for doing Debian talks (with
> a little bit of HP advertising) if you're no more leader next year ?
It's hard for me to predict that. My work objectives at HP explicitly
mention continuing to make public appearances, but some of the trips I made
in the last year were justified "because the DPL should be there" more than
because of any direct business value to HP.
I have already accepted invitations to speak at various events in the coming
year, so I will certainly continue some amount of travel and speaking on
behalf of Debian whether I am re-elected or not.
> You explain that the main DPL task is "facilitation", I think that
> anyone can do this work of "facilitation", how does it help to be DPL
> for this task ?
The things I call "facilitation" are things I've been doing since long before
last year's election, and which I certainly hope to continue long after my
service as DPL ends.
I think there are two ways in which being DPL helps with this task. Many
more people have addressed me directly looking for help in the last year
than ever before, which I assume is the natural tendency to look to a leader
for help. And, as DPL, I've felt a greater responsibility to read email and
listen to what people are saying on topics outside my natural areas of
interest in the project. That gave me more context in which to help point
people in the right direction.