In our current arrangements, the TC is the only body who can rescue a
package from a maintainer who is determined to sit on it.[1]

The TC have never exercised this power, when a maintainer has insisted
that they want to keep maintaining the package.

It is surely obvious that there must have been several occasions in
the history of the project, where someone has been such a poor
maintainer that they ought to have been deposed, with someone ready to
take up the role.  The only possible conclusion is that our process
for dealing with bad leadership on the part of maintainers is totally

There is a recent case where:
 * The maintainer has done nothing to the package for many years,
   other than infrequent (and usually short) emails to NAK
   contributions from others;
 * The package is years out of date compared to upstream, afflicted by
   bitrot, and many users are asking for the new version;
 * Several times, proposed updates have been prepared by contributors
   but blocked by the maintainer;
 * There are new maintainers ready and waiting, with a new package
   ready for upload to sid for stretch;
 * Now that the TC is involved the maintainer has written many emails
   explaining their decisions to NAK uploads, but TC members are
   clearly unconvinced on a technical level that those decisions were
Even in this extreme situation the TC has not seen fit to wrest the
package away from the mainainer's deathgrip.

I don't know exactly why the TC is so useless at challenging poor
maintainership.  I think part of it is that our TC is supposedly
focused on technical issues.  The TC likes to try to solve a technical
problem while "keeping everyone happy".

This is of no help if real underlying cause of the technical problems
is not a technical disagreement, but rather poor management by the
maintainer.  In that case "keeping everyone happy" means keeping the
most stubborn people happy.  It means keeping the bad manager in
charge, while those who don't want to fight simply go away,

TC members tend to reframe efforts to solve the leadership problem, as
personal attacks.  And of course, that is a real difficulty: since
maintainership is a personal authority, it is hard to suggest that
someone's authority should be weakened without criticising how it has
been wielded, and implicitly criticising that person.

I also think that TC members are probably biased, by selection.  All
TC members have extensive experience of maintainership (either within
or outside Debian), and/or of core team membership.  They have long
experience of wielding authority, and of negotiating from a position
of authority with peers.  They will probably have had recent (and to
them salient) experience of being challenged by useless supplicants;
whereas their experiences of being blocked or rebuffed by useless
maintainers will have been less common, and have less of an overall
impact on their participation in Debian.

This will tend to make TC members more comfortable with the existing
massive power imbalance between maintainers on one hand, and
other contributors on the other.

And of course for very good reassons, many of the kind of people we
put on the TC are very conservative: they tend not to like change,
particularly change to social structures.

Other difficulties include the requirement for transparency in TC
deliberations; and the difficulty of dealing simultaneously with
social and technical problems (and the consequent temptation of
technically focused people to just fix the software, where answers are
clearer, and think or hope that that is enough).

Regardless of the reasons, this is not good enough.

Maintainership is a leadership position, with serious governance
authority.  Leaders must be accountable.  Bad leaders must be

It is clear to me that the TC (the structure I set up for this purpose
when I wrote the constitution) is not delivering and probably never

There are three obvious options:

1. Recognise that Debian will never depose a maintainer, no matter
   what.  Maintainers are, within their packages, dictators (subject
   only to the possibility of TC overrule on individual issues, which
   is itself very very rare).  The only way to get rid of a bad
   maintainer is to wear them down unti they eventually go away.

2. Provide a new process for deposing a maintainer, or appointing

3. Abolish maintainership entirely.

Of these 1 is what we have now.  I think it is entirely unacceptable.
I don't think the project is politically ready for 3.  Also, it would
be awkward to see how 3 would work in practice: are competing
contributors expected to play core wars in the archive until the TC
makes a decision in each case ?  What a nightmare.  That leaves 2.

The key question for such a new process is: who will decide ?

It is very tempting to model such a thing on our existing
constitutional structures.  For example, we could create a team like
DAM, whose job was to take (private) requests for
mediation/intervention, and who would eventually make some kind of

But I would like to make a more radical suggestion.  We should make
these decision by juries, rather than committee.

For each such dispute, we should pick a panel of randomly chosen DDs,
and have them decide (with a time limit).

In more detail:

An aggrieved contributor, the complainant, would first contact a
mediation team, privately.  There would be some overlap with MIA, I
guess.  Hopefully things can be resolved through mediation.

If the mediation does not result in satisfaction, a DD complainant
would send an email to a robot, giving the names and addresses of

The robot would select a random panel of (say) 10 DD.  (There would
probably have to be a ping back phase to make sure the chosen weren't
MIA.)  There robot would set up two mailing lists: the panel; and the
complaints and existing maintainers together (for the maintainers,
personal addresses, from, Uploaders, for a "team" maintained package).

The complainants would send an initial summary to both lists; the
maintainers would prepare an initial reply, to both lists.  Messages
to the panel list but not the two-sides list, other than from panel
members, would be rejected.  If a panel member feels that private
input is required from one side, they can ask for it and forward it

The panel would discuss matters for a period of two weeks.

The complainants and maintainers would be CC'd on the initial mails.
At the end of two weeks they would vote.

By a simple majority, the panel either reaffirms the maintainership of
the existing maintainers/uploaders, or transfers formal maintainership
to people nominated[2] by the complainants.

We would implement this constitutionally by giving the DPL the power
to define a process by which maintainers may be replaced.  Probably
the GR would come with an initial cut of that process.


[1] In theory deposing a maintainer could be done by a GR but that
    would be a nightmare.

[2] Nomination of the new maintainers should be done at this stage.
    Thus a a frustrated contributor who, if the petition fails, needs
    goodwill of the curent maintainer, can ask others to front the
    complaint and argue the case.  This helps minimise the justified
    fear of retaliation.

Ian Jackson <>   These opinions are my own.

If I emailed you from an address or, that is
a private address which bypasses my fierce spamfilter.

Reply via email to