The “Debian board” has been discussed a lot recently. I’m not so convinced it will improve matters that much.

I don’t think Debian is lacking a central authority to keep the vision. Most people have some overall vision; these visions might disagree on some points, but a board is bound to have the same disagreements.

What is taking the fun out for me is not that some technical matters don’t work out the way I want them too, but usually it’s lack of manpower in certain files of particular interest to me. For example SELinux has been rather frustrating for me, since I felt like fighting alone on a lost position. Often applications would change faster than the policy could be updated etc. And trying to support sarge made that even more so. Sometimes bugs were fixed upstream, but the packages in Debian weren’t updated yet, etc.

When I was maintaining galeon back then, the must frustrating things were that on one hand, you had lots of people complaining about galeon 2 being different from galeon 1 (and not accepting that galeon 1 was dead upstream, I preferred galeon 2 and so obviously packaged galeon 2) - and on the other hand that there were tons of open bug reports noone even had time to verify. Working on such a package can be very frustrating.

I’ve been keeping out of flamewars and such for quite some time, so I’m not so much bothered by that. I’ve blogged about that before.

But I don’t see where a “board” or “steering commitee” would come in helpful. Especially not in comparison to DPL-named release managers etc.

IMHO it would be helpful to bring more people in. Our process of becoming a DD is very demotivating, and actually we could use more people - especially - for things like bug verification.

Contributing to Debian can be demotivating for several reasons:

  • Packages where the maintainer doesn’t respond
  • Packages the maintainer doesn’t really care about
  • Packages where you don’t understand the packaging, because it’s too different from what most packages use (i.e. please use debhelper and maybe CDBS for your packages, don’t build your own 20k makefile buildsystem)
  • Often not easy to create proper patches
  • Roundtrip times of bugtracking etc.

Stuff I’ve been enjoing:

  • “Thank you”s at the end of bug reports
  • Occassional teasing by helix for complaining too much in my blog
  • Real life meetings of debian-MUC
  • Team-maintained packages

What I’d love to see on the long run is some kind of central package repoistory. Many other distributions use some kind of huge version control system for managing all their packages. Maybe we could have something like this with two “default” branches. With very little effort you can get write access to the “public” branch, and only full developers can pull patches over to the “authorative” branch. Packages should be built from that branch, and use some uniform way for this (e.g. debian/patches/ directories!)

But people with more experience in team maintainance, e.g. the Gnome team, can hopefully comment more on this.