Re: Replace the TC power to depose maintainers
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
>
> This is the obviously right solution.
I can see why this is attractive. But as I say I we need a way to
deal with disagreements that aren't (for any reason) resolved by
amicable discussion.
The current resolution to such disagreements is that the "maintainer",
who is usually the person who produced the previous version, decides.
This approach has the virtue of stability.
And it is this very rule which is the problem. If you propose to
solve the stop-energy maintainer deathgrip problem by abolishing
maintainership entirely, you need to replace it with something.
Otherwise it really will be chaos, with people uploading
contra-reverts of each others' reverts. If we simply remove
maintainership and say "do as you like" we are actually encouraging
such hostile behaviour.
> We should go for "weak code ownership" instead, which *in theory* is
> what we already have (given every DD can NMU any package),
I'm not sure about the definitions of the terms `weak' vs. `strong'.
Our current documented processes, in the Developers' Reference, give
the maintainer final decision about nearly everything.
I would definitely support changes to the Developers' Reference to
weaken our sense of code ownership. Such changes should have the
explicit blessing of the DPL, so that there is a promise of support
from `the management' if friction should arise the first few times the
approaches are used.
Having said that, if we have any kind of documented maintainership at
all, that means anything, nonconsensually removing someone as a
maintainer is sometimes going to be necessary sometimes. That's never
going to be fun, and we need a just and respectful way of doing that.
I would like to make a counterargument in defence of maintainership.
I am a believer in stability, and in relying on the judgement of our
people. Ownership supports an emotional connection with the work
which I think is very valuable in a project with many volunteers.
Of course there are downsides, but most maintainers - even most sole
maintainers - in Debian manage their packages well.
Let me give some personal experience:
I'm the kind of person who always trips over weird edge cases; I have
high standards of reliability and error handling; and I often feel I
have a clear vision of what the tool I was using ought to have done.
As a result, over the years and decades I have filed a great many
bugs. Some of these bugs are extremely obscure. Some of them are
difficult to fix. Some of them are consequences of erroneous upstream
design decisions.
In the vast majority of cases my interactions with the maintainers of
these packages have greatly benefited from the maintainer's ownership
(in the broadest sense). Maintainers have taken pride in and
responsibility for the software under their care. They have engaged
with an open mind. They have engaged to explain my concerns to
upstream. They have put major rework on their todo lists. They have
given me good and helpful advice about workarounds.
(And of course, I have probably become better over the years at
engaging with more empathy, when I'm filing a bug.)
As a whole, Debian maintainers are not only exceptionally talented. I
have found them to have great generosity of spirit.
But of course not everyone can be perfect all the time.
I don't think to solve the problem of the small number of hard cases,
that we need to abolish the institution of maintainership entirely.
I just want to reframe it a bit, by changing the backstop:
Power relations always colour human interactions. (Power relations
are about what happens if agreement and consensus cannot be reached:
they are about who ultimately decides.)
I want to disempower maintainers just a little bit, by providing
structures, instutitions, or people, who will (in a sufficiently bad
case, or when asked) look over the maintainer's shoulder.
An aside:
> we don't have good tools[^] that make it trivial to integrate back
> changes that have been NMUed by others
>
> [^] well, we have dgit, but AFAICT is not really popular yet
If you as a maintainer use dgit, you can integrate an NMU using the
dgit suite branch even if the NMUer didn't use dgit.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: