[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: question for the candidates

Joey Hess wrote:
I see many of good ideas for ways to improve the project in several of
your platforms. If you are not elected DPL, which of those ideas do you
still expect to be able to work on? How will you be able to do it
without the power of being DPL?

So, the first plank of my platform is about making Debian a more
pleasant and attractive project to contribute to; I've tried in the past
to argue against various unpleasant features of the lists, but looking
at the results, I don't think that approach works. I can't really think
of any other approaches that don't require activity from someone in
authority, ideally the DPL. Without either being the DPL, or the DPL's
pretty active and forthright support, I don't really see a lot that can
be done there. Likewise, trying to make it clearer how the project makes
decisions and reducing acrimony over it also seems a task that should be
primarily undertaken by the DPL.

A further problem is that without those issues being solved, working on
Debian is often somewhat painful; and I suspect if whoever's elected DPL
doesn't come find some way of resolving some of the issues above, I'll
be focussing on the things I'm currently working on and involved in
rather than trying anything much new.

Yeah, yeah, caveat, caveat, caveat, I know. Anyway. Most of the other
things can at least be worked on without Super-DPL-aciousness. Involving
users more is just a matter of working out in what ways people can be
usefully involved, setting up support for it, and following it through.
Improving the project's mentoring processes is fairly straightforward
too; and Helen Faulkner and the debian-women group have demonstrated you
don't even have to be a developer to make a difference there. QA work
likewise is a matter of sitting down and working on the problems, and
doesn't need any special powers to perform. Collecting our various
policies into a single document, is mostly a matter of, well, collecting
our various policies into a single document and maintaining it.

Package selection has been an issue for years; and aptitude and other
projects have already implemented partial solutions. Improving the
situation there is mostly a matter of getting the various ideas actually
into collated, written down, and organised more effectively -- eg, I
think it would be far better to have aptitude's function_pkgs and
function_groups information in the Packages files, rather than centrally
maintained in aptitude. That's been discussed in the past, but probably
needs some more active, cross-project leadership to actually get
finished. If it does go anywhere, I expect I'll be involved in getting
it implemented with my ftpmaster hat on.

As far as trying to get derived distros more closely integrated into
Debian goes, without being DPL or involved in any such projects, I
suspect my involvement would also be limited to implementation roles --
eg, working out how to best incorporate the changes Ubuntu or Knoppix
have made in order to make them useful on their own and available to
Debian maintainers, or whatever; or working out what changes the BTS
needs in order to deal with those patches and possibly support multiple
maintainers. But without the DPL or the derivatives getting involved in
working out what sort of better integration is useful, I don't see that
progressing to the point of implementation anyway.

On most of these things I'd expect, if I were DPL, to help more in a
meta-leadership role anyway; that is finding someone who can take the
lead in doing the work, and helping them do a good job at that.
Certainly there's way more work in that than one person can do. And
conversely, I'd certainly consider working on any of the
DPL-Superpower-Needed tasks I mentioned if someone else was elected DPL
and was interested in lending me their authority.


Reply to: