Re: Questions for the candidates
* Anthony Towns <aj@azure.humbug.org.au> [2004-03-02 20:11]:
> First: "The Debian Project is an association of individuals who have
> made common cause to create a free operating system." Presumably
> this means our primary focus should be on putting together great
> free software and getting it out to users.
That's right; this is the vision I share and the goal I'm working
towards.
> If the Project Leader is the public face of the project, is the
> person to whom developers look for an example, shouldn't the
> leader's primary focus also be on technical improvements? If so, why
> do your platforms instead focus on process issues?
There is evidence that a high quality product requires high quality
processes ...
> If not, how do you propose that Debian developers remain focussed on
> creating a free operating system if you're going to be focussed on
> different goals (such as "how to be nice to each other")?
... I am focused on creating a free operating system. Creating a free
operating system requires more than pure development. For example,
you also need a good infrastructure (such as an ftp archive). There
are many ways to contribute to a free operating system other than
strictly through development (translations would be another example,
or usability studies). As I argued in my platform, my contribution is
to coordinate different efforts in Debian. You can see me as the glue
which keeps all the developers working together. I'm proud to be
working together with some really smart free software developers, and
my main task is to ensure that they can carry out their work.
> As Gergely was the only candidate to address any technical issues
> directly, can you provide those of us who think technical issues are
> by far Debian's prime concern any reason to vote for anyone other
> than him?
I think technical issues are important, and I am involved in technical
decisions as well. In my work, I stay in contact with many developers
and give them advice, both on technical issues themselves and on how
to implement technical things.
> Ignoring the communication and timliness issues, do you think there
> are any significant problems in the execution of the tasks under
> discussion? Do you think, for example, that any new-maintainers who
> have been accepted should have been rejected, or vice-versa? Have
> any people applied to join some of the teams in question and been
> rejected, whom you think should have been accepted, or vice-versa?
> On balance, do you think any of the teams are doing any of these
> jobs inadequately? In each case, if so, which and why?
I mentioned the security team in my platform as one example. I think
they are doing an _excellent_ job, but I am also aware that they are
quite overworked and that they could help additional man power. As to
offers being rejected: I think if this happens it is largely due to
bad communication or approaching people the wrong way. In your mail,
you mention the example of saying "This FUCKING SUCKS! The maintainer
must be incompetent or on crack". From my experience, this approach
usually does not work. Similarly, if an offer to help is phrases
poorly, it probably won't get accepted. I see it as my task to advice
people on how to get involved in various work (either package
maintenance, core teams or core projects, such as debian-installer).
I know many people in Debian and how they work, and so I can approach
them in the way which works for them and tell other people who to
approach them.
> Ignoring the communication issue, do you think any of the relevant
> tasks are being done too slowly? For example, do you think the new
> maintainer applicants who have been rejected should have been
> rejected sooner? Or do you think NEW packages for the archive should
> be processed quicker?
NEW packages are usually processed within 2 weeks, and I'm quite happy
with this. The first applicant who got rejected should have been
earlier, but it took a long time to get the procedures right; again,
this was the first formal DAM rejection and it's important to
formalize the process. So while it would have been good to have done
the rejection earlier, I think it was important to take the time to
get it right. The few other rejections which have happened since then
were all done in an adequate timeframe. For those interested in this
topic, I have written a pretty thorough analysis about rejections at
http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg01369.html
> If you think any of these tasks are not being done in a timely
> enough manner, how would you compare the effect of these delays to
> other work that takes time, such as development of our installer, or
> major stable releases, or packaging new versions of X, or fixing
> release critical bugs? By what criteria would you distinguish the
> tasks above that the project needs to focus on speeding up, and the
> ones which are already acceptable -- given that improving them all
> would obviously be a win.
I think there are many development processes which have to be sped up
as well. As you can see from my recent "Bits from the DPL" posting at
http://lists.debian.org/debian-devel-announce/2004/debian-devel-announce-200403/msg00000.html
I talked to Keith Packard to discuss the future of X and ways of
having more up to date packages in Debian (breaking up X into
components should help), and I asked Keith to contact Branden to
discuss this further. I am also quite closely in contact with the
debian-installer team. While I have tested debian-installer and
reported bugs myself, my main contribution is to make sure that the
debian-installer people can get their work done. For example, I
managed to get a laptop on loan to Joey Hess which has improved his
test cycle significantly. I've done similar things for other
developers. Also, I got more developers involved in debian-installer.
For example, I talked to Vincent Sanders several times to stress the
importance of putting more work into ARM, and this has happened.
Similarly, I asked a S/390 related company if they can help and put
them in contact with Bastian Blank, who is doing most S/390 d-i work.
As to RC bugs: I'm not very happy with the status at all. I help
decrease RC bugs in various ways. Through my MIA effort, I find
inactive maintainers and orphan their packages so others can take
over. Also, I once organized a group of QA people to help out busy
maintainers, and I intend to put more work into organizing a systematic
QA effort (see my platform). Finally, I often mail developers and ask
them to please get their RC bugs, and this often helps. (The latter
is one part of the "coordination efforts" which I mention in my
platform.)
(I mentioned in my platform that I found that people are mainly
interested in maintaining packages. I also found that they are mostly
interested in maintaining _their own_ packages - we have to motivate
people to help out other maintainers who are busy or over-worked; we
have to promote co-maintenance, and we have to find inactive
maintainers and take their packages away - something I've been working
on for years with pretty good success.)
> For those tasks that the project should focus on speeding up, how do
> you propose that this be achieved? Why has it not been achieved
> already? Given that Debian is developed by volunteers, and
> presuming you're not able to fix everything yourself, how do you
> propose to get other people to do what's needed, given they haven't
> already wanted to do it?
In many cases, it often helps to simply remind someone in private mail
to fix their RC bugs or packages. It is important to keep the overall
picture of the status of Debian into account, and then regularly
contact those who need to fix their packages/bugs. So most of my
contribution is to get maintainers to actually fix their bugs, rather
them fixing it for them. I motivate people to do their work, I find
people who can help out with specific areas - again, I coordinate.
> On the communication issue, presuming you were elected unanimously
> because everyone agreed with your plans and worked to put them into
> effect to the best of their abilities, what would the project look like,
> ideally? Would there be more communication than there is at present? From
> whom, in what forums, and what activities would be covered? Should
> there be "nothing's changed" announcements made, or should that be
> implied by a lack of updates on tracking pages? Which announcements
> should be made on -announce, -devel-announce, -devel/-project/-user,
> -apache/-dpkg/-gtk-gnome/-perl/-qt-kde/etc?
I don't think we need "nothing's changed" announcements, but sometimes
important changes are not properly being documented or announced. The
forum where the announcement takes place depends on the message and
audience. I think all the lists you mention are good candidates.
Myself, I have posted status reports to -devel-announce, worked with
Joey to get some important announcements to -announce. I have also
forwarded various mails to -devel and -project which I think are of
interest to other developers (for example, when comments for the beta
of LSB and FHS were requested, I forwarded this mail; I forwarded a
mail about an academic paper on Debian, etc). I follow many mailing
lists, and see it as my duty to inform other developers there is
anything of interest (I also do so in private mail if it's only of
interest to one developer; for example, I mailed Enrico Zini a paper
about usability because I know he is interested in this area).
> Should any just be mentioned in passing on irc, or in a discussion
> thread on a list without being announced more widely than a CVS log
> or a package changelog otherwise?
While I personally follow IRC, a lot of mailing lists (including
-bugs-dist and -devel-changes) and other forums, I acknowledge that
not everything is in a position to do the same (it does take some
time). I therefore think it's important to provide summaries, and to
forward important messages.
> Do you believe that developers should be (or are) equally willing to
> have a dialogue with people who provide criticism consisting of
> suggestions of alternatives, discussion of tradeoffs that can and
> should be made and helpful bits of code, or people who accompany
> their complaints with comments like "This FUCKING SUCKS! The
> maintainer must be incompetent or on crack" and requests for
> dismissal or replacement rather than useful assistance?
I, as DPL, am willing to listen to them because there concerns might
be valid. However, I don't think that most people will listen to a
mail which basically says "YOU SUCK". Again, I think communication is
important, and this applies to everyone. We have to help people
express what they really mean, in a manner which other people can
understand and don't find offending.
> If you think that they should be equally willing to do so, how do
> you propose to motivate people like myself, who aren't equally
> willing, or how do you propose to work around that concern? If you
> think that no such equal willingness is required, how do you propose
> to promote the former form of reaction and criticism compared to the
> latter?
I don't think it's in human nature to be equally willing to listen to
anybody; if someone says "YOU SUCK" you'll probably ignore it. My
task is to tell people that this form of communication is not
productive, or to translate their message into something more
productive.
> Who do you think should be subscribed to -devel, and what sort of
> discussions do you think should make up the majority of the traffic?
> If reality doesn't match those desires, what, if anything, will you
> do to change that?
I think that _everyone_ should be subscribed to -devel, and it's sad
that a growing number unsubscribe because of flamewars and other
discussions which are not productive. I think -devel should be a list
for technical discussions, and by improving communication and
processes in the project I hope to decrease the amount of flamewars
and get people back on -devel.
--
Martin Michlmayr
tbm@cyrius.com
Reply to: