Leaderless Debian

About 10 years ago I was responsible for some servers running Fedora and some servers running Debian. Fedora's update cycle was way too fast, but we also knew that switching to CentOS would get us software that was way too behind to be useful, and we'd be responsible for building a lot of stuff in /usr/local ourselves.

A small technical difference is that the dpkg ecosystem has a feature called "diversions" that let you cleanly say that you want to replace a packaged file. A config management system can use this to avoid having config management and the package manager fight each other. I'm the current maintainer of https://github.com/sipb/config-package-dev , a tool that lets you build Debian packages that express system configuration, and I've ended up using it at 3 of my last 4 jobs. For the Fedora servers, we were using some mix of checking out /etc from Subversion and rebuilding packages on our own. We surveyed our options and determined that we weren't really better off with any of the "real" config management options at the time (to be fair, modern config management hadn't really taken off then) and the lack of diversions meant we were better off rebuilding packages that we wanted to make changes to.

As a consequence, Debian packaging policy is (in my experience) a lot more aggressive about using detailed dependency-resolution metadata to establish constraints and define compatibility, which makes for a more annoying developer experience but a nicer end-user experience.

  A) of software - DFSG
  B) of decisionmaking - Debian constitution
  C) of choice

  * both installed program and source is just an apt command away (A, C)
  * has a large repository of software (historically largest; nowadays it's still among the largest) (A, C)
  * security support for stable release for the whole archive (cf. Ubuntu, RHEL) (A)
  * software from repository aims to play nice together (C)
  * true community distro, independent from any single vendor (B)
  * multiple kernels, multiple desktop environments, multiple init systems, a truckload of architectures (C)

Even if nobody puts their name this week or the next or the week after, and even with the sarcastic remark in the last sentence, it looks like this is not such a big deal after all.

> In other words, the project will manage to muddle along for a while without a leader, though various aspects of business could slow down and become more awkward if the current candidate drought persists.

Why should it muddle along or slow down? All the responsibilities listed (and linked to in a mail in the mailing list) seem to be things that others could take up, either individually or as smaller groups. It's something that could be worked out over a period of time.

> One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it.

The last sentence is probably the issue. Couldn't sponsorships help? The last thing we need is Debian to become corporatized.

Donate to Debian at https://www.debian.org/donations

As someone who no longer uses it but has a lot of history using Debian I hope you are correct and that this latest issue of not finding a leader according to the standard schedule is just something they route around. Based on the tone of the end of today's article it sounds like that's the case.