Re: Replace the TC power to depose maintainers [and 1 more messages]
Since I didn't want to sent too many more emails, I'll make three
short replies in one email...
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead, which *in theory* is
> what we already have
Well, no. What we have is a kind of sticky door when the current code
owner is cooperative. And many other people have various amounts of
influence. The release team have a certain amount of power. But if
the current code owner is uncooperative, they have almost absolute
hard power.
The TC has never desposed an existing maintainer, and very rarely even
overturned an individual decision.
In the past years the most effective check on absurd maintainer
behaviour has been the Release Team, who have functioned in many cases
as an effective backstop. This is why we have so many arguments about
what counts as an RC bug: If you have tried talking to the maintainer
with no success, getting your bug declared RC by the Release Team is
the only effective way to get the uncooperative maintainer to accept
your patch.
> (given every DD can NMU any package), but the
> *culture* of strong ownership is so rooted in the project that people
> are still too afraid of using it.
If you actually do a nonconsensual NMU in this way, ftpmaster might
remove your package from the queue. That has happened in the past.
That every DD can upload every package is a technical ability, not
permission.
A DD who uses that technical ability to do the job of the TC (in an
act of "civil disobedience" to the Constitution) will usually find
that their actions are undone or reversed by the project's other power
structures.
Normally, as someone who supports the rule of law, I would think that
a good thing. But in Debian the rule of law means the rule of the
current maintainer.
Paul Wise writes ("Re: Replace the TC power to depose maintainers"):
> On Sat, 2016-12-03 at 10:27 +0000, Ian Jackson wrote:
> > Mainly, it was a way to control who got email about the package.
>
> Why was it called Maintainer instead of something more suitable then?
Because it's useful to know who to talk to about a package. Frankly,
the kind of governance difficulties that arise in a project with many
thousands of contributors weren't at the front of our minds...
Holger Levsen writes ("Re: Replace the TC power to depose maintainers"):
> So I'm wondering, maybe instead of getting rid of the
> maintainer field, we should get rid of the uploaders field and allow several
> maintainers in the maintainers field? I dunno.
We should definitely do this. I don't think it it would be
controversial but also I don't think it would fix anything.
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: