Re: Replace the TC power to depose maintainers
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead,
I was thinking about what Scott wrote, and also went back and read
some of the bug log he is referring to. I wonder if there is an
underlying a useful observation about the merits of team maintenance.
Most of the really bad cases I have seen have been a single
maintainer. In packages with more than one person involved, even if
there is someone in the team whose communication skils are not
brilliant, it is normally possible to work with the rest of the team.
There is of course a possibility that a whole team might get a kind of
groupthink. I have indeed seen that in a few situations, but it is
obviously very rarely practical to replace a whole team, even if a
decision to do so could somehow be made.
Can we come up with some way whereby the maintainership authority is
always shared, somehow ? Either with a team, or with the whole
project (QA-style), or with the first person who comes along and wants
to try to help ?
Is there a way to do this that would work in practice ?
Some ideas:
* Document that all packages ought to have several maintainers, if
there are people available to do that job.
* A new rule that for a package where only one human being is named
in Maintainer/Uploaders, any DD who wants to help the package
SHOULD add themselves to Uploaders and thereby become a maintainer
equal in standing to the existing maintainer.
That is, discourage NMUing a sole-maintained package, in favour of
joining its as a maintainer - importantly, to encourage joining as
a maintainer without asking first.
So the process would be:
Alice sees that a package is solo-maintaineed, and there is
something she wants to fix in it. She uploads to NMU/DELAYED-7
adding herself to Maintainers, and maybe fixing any easy RC bugs.
She also simultaneously emails the maintainer to introduce herself,
offer her help, and consult on plans for the future of the package.
Something like:
Hi, Bob. I was looking at gnomovision, and saw that you seem to
be dealing with it alone. I would like to help so I have taken
the liberty of becoming a maintainer, with my upload which I
have just pushed to DELAYED-7.
I also fixed #890123 (the RC bug) in what I hope is the right
way. Please let me know if I got it wrong.
To be honest, I don't have a great deal of time for doing major
work on gnomovision but I can help deal with obvious problems
and help keep the package in tolerable shape. As you will know,
we (Debian) recently decided that it's better for me to formally
become a maintainer of a package which would otherwise have only
one person looking after it.
I hope this all seems good to you and I look forward to working
with you.
Regards,
Alice.
* Change the dev ref so that if a package has only one maintainer,
any upload should be considered a maintainer upload and the usual
NMU rules do not need to be followed ?
Probably bad because no-one will want to do such a hostile act.
* Explicit authority for the MIA team to declare that someone is no
longer a maintainer, to avoid Maintainer fields giving the
appearance of multiple maintainers when actually there is only one
maintainer right now.
* Disputes within maintainership teams might have to end up in front
of the TC, more often. But then the question is much more "what is
the best way to do X or Y".
* Maintainership to be recorded elsewhere so that it is not
neccessary to upload to change the maintainer.
There could be a web UI in which SSO-logged-in DDs could see a
"join team for this package" button which would automatically join
the team if there was a sole maintainer, but would turn into an
"apply to join the team" button if there were at least three
existing maintainers.
Or something.
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: