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 <ijack...@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.