Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.project > #8869 > unrolled thread
| Started by | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| First post | 2016-12-01 16:50 +0100 |
| Last post | 2016-12-07 12:00 +0100 |
| Articles | 20 on this page of 107 — 30 participants |
Back to article view | Back to linux.debian.project
Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 16:50 +0100
Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 17:20 +0100
Re: Replace the TC power to depose maintainers Sean Whitton <spwhitton@spwhitton.name> - 2016-12-01 18:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 19:00 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 18:50 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-01 19:10 +0100
Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 19:30 +0100
Re: Replace the TC power to depose maintainers Sheetal Shalini <sheetalsh456@gmail.com> - 2016-12-03 11:40 +0100
Re: Replace the TC power to depose maintainers Jérémy Bobbio <lunar@debian.org> - 2016-12-03 21:30 +0100
Re: Replace the TC power to depose maintainers Andreas Tille <andreas@an3as.eu> - 2016-12-08 16:30 +0100
Re: Replace the TC power to depose maintainers Vincent Bernat <bernat@debian.org> - 2016-12-01 19:10 +0100
Re: Replace the TC power to depose maintainers Clint Adams <clint@debian.org> - 2016-12-01 19:30 +0100
Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-01 19:40 +0100
Re: Replace the TC power to depose maintainers Stefano Zacchiroli <zack@debian.org> - 2016-12-01 19:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 12:50 +0100
Re: Replace the TC power to depose maintainers Johannes Schauer <josch@debian.org> - 2016-12-02 13:40 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 14:00 +0100
Re: Replace the TC power to depose maintainers Adam Borowski <kilobyte@angband.pl> - 2016-12-02 16:10 +0100
Re: Replace the TC power to depose maintainers Iustin Pop <iustin@debian.org> - 2016-12-02 20:40 +0100
Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-02 13:20 +0100
Re: Replace the TC power to depose maintainers Johannes Schauer <josch@debian.org> - 2016-12-02 13:50 +0100
Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-02 14:50 +0100
Re: Replace the TC power to depose maintainers Mattia Rizzolo <mattia@debian.org> - 2016-12-02 16:30 +0100
Re: Replace the TC power to depose maintainers Raphael Hertzog <hertzog@debian.org> - 2016-12-02 23:30 +0100
Re: Replace the TC power to depose maintainers Paul Wise <pabs@debian.org> - 2016-12-03 07:00 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-03 11:30 +0100
Re: Replace the TC power to depose maintainers Paul Wise <pabs@debian.org> - 2016-12-03 11:50 +0100
Re: Replace the TC power to depose maintainers Sheetal Shalini <sheetalsh456@gmail.com> - 2016-12-03 11:50 +0100
Re: Replace the TC power to depose maintainers David Bremner <david@tethera.net> - 2016-12-03 12:20 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 12:40 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Russ Allbery <rra@debian.org> - 2016-12-05 18:50 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 19:10 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Lars Wirzenius <liw@liw.fi> - 2016-12-05 19:20 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Lars Wirzenius <liw@liw.fi> - 2016-12-05 20:10 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Laura Arjona Reina <larjona@debian.org> - 2016-12-05 20:10 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:10 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:10 +0100
Re: Replace the TC power to depose maintainers [and 1 more messages] Tollef Fog Heen <tfheen@err.no> - 2016-12-06 05:30 +0100
Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 09:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Adam Borowski <kilobyte@angband.pl> - 2016-12-06 10:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 15:00 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Adam Borowski <kilobyte@angband.pl> - 2016-12-06 15:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Holger Levsen <holger@layer-acht.org> - 2016-12-06 15:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 16:00 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Lars Wirzenius <liw@liw.fi> - 2016-12-06 16:10 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Johannes Schauer <josch@debian.org> - 2016-12-06 16:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Lars Wirzenius <liw@liw.fi> - 2016-12-06 16:30 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 16:50 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Enrico Zini <enrico@enricozini.org> - 2016-12-11 19:50 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:30 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 02:40 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 03:00 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 03:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 14:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Scott Kitterman <debian@kitterman.com> - 2016-12-12 15:30 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 18:20 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Philip Hands <phil@hands.com> - 2016-12-12 18:20 +0100
Re: Formal declaration of weak package ownership in source packages Russ Allbery <rra@debian.org> - 2016-12-12 19:40 +0100
Re: Formal declaration of weak package ownership in source packages Vincent Bernat <bernat@debian.org> - 2016-12-12 09:30 +0100
Re: Formal declaration of weak package ownership in source packages Scott Kitterman <debian@kitterman.com> - 2016-12-12 13:50 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Holger Levsen <holger@layer-acht.org> - 2016-12-06 16:40 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Christian Hofstaedtler <zeha@debian.org> - 2016-12-06 18:40 +0100
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 14:50 +0100
Re: Replace the TC power to depose maintainers Andreas Tille <andreas@an3as.eu> - 2016-12-08 16:40 +0100
Re: Replace the TC power to depose maintainers Rhonda D'Vine <rhonda@deb.at> - 2016-12-09 13:10 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:20 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-02 16:50 +0100
Re: Replace the TC power to depose maintainers Holger Levsen <holger@layer-acht.org> - 2016-12-03 11:50 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-03 18:40 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-03 23:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 12:10 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 19:30 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:20 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:10 +0100
Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-05 23:20 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 00:20 +0100
Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-06 01:00 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 15:10 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-06 05:40 +0100
Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 15:20 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-06 15:30 +0100
Re: Replace the TC power to depose maintainers Stefano Zacchiroli <zack@debian.org> - 2016-12-07 11:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-07 12:00 +0100
Re: Replace the TC power to depose maintainers Scott Kitterman <debian@kitterman.com> - 2016-12-08 07:40 +0100
Re: Replace the TC power to depose maintainers Piotr Ożarowski <piotr@debian.org> - 2016-12-08 11:30 +0100
Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers) Guillem Jover <guillem@debian.org> - 2016-12-08 03:20 +0100
Re: Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers) Raphael Hertzog <hertzog@debian.org> - 2016-12-09 11:40 +0100
Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 15:20 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 15:50 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 19:50 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 15:50 +0100
Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-05 16:10 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 18:50 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-05 23:00 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 21:20 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 22:10 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-05 22:20 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-05 22:50 +0100
Re: Replace the TC power to depose maintainers Matthew Woodcraft <matthew@woodcraft.me.uk> - 2016-12-05 23:20 +0100
Re: Replace the TC power to depose maintainers Philip Hands <phil@hands.com> - 2016-12-10 07:50 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-12 02:40 +0100
Re: Replace the TC power to depose maintainers Tollef Fog Heen <tfheen@err.no> - 2016-12-16 13:30 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-16 14:10 +0100
Re: Replace the TC power to depose maintainers Russell Stuart <russell-debian@stuart.id.au> - 2016-12-07 00:10 +0100
Re: Replace the TC power to depose maintainers Didier 'OdyX' Raboud <odyx@debian.org> - 2016-12-07 09:40 +0100
Re: Replace the TC power to depose maintainers Ian Jackson <ijackson@chiark.greenend.org.uk> - 2016-12-07 12:00 +0100
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-01 16:50 +0100 |
| Subject | Replace the TC power to depose maintainers |
| Message-ID | <sJBMt-5TK-7@gated-at.bofh.it> |
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
broken.
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
right.
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,
discouraged.
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
replaced.
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
will.
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
co-maintainers.
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
decision.
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
co-complainants.
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
themselves.
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.
Ian.
[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 <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.
[toc] | [next] | [standalone]
| From | Mattia Rizzolo <mattia@debian.org> |
|---|---|
| Date | 2016-12-01 17:20 +0100 |
| Message-ID | <sJCfv-6mQ-15@gated-at.bofh.it> |
| In reply to | #8869 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> 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
> right.
> Even in this extreme situation the TC has not seen fit to wrest the
> package away from the mainainer's deathgrip.
We have a very similar case within the MIA team (the willing contributor
contacted us instead of the TC). The only difference is probably that
the maintainer sent his NAK to me on IRC instead of in a email, and now
he is not doing that either). The difference is that on paper we don't
have the authority to "wrest the package away"; but I can't even mediate
given that this person is not replying....
(this is this case reported in d-d:
https://lists.debian.org/debian-devel/2016/11/msg00320.html )
> 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.
This is silly. We have a issue that really needs resolving.
> 2. Provide a new process for deposing a maintainer, or appointing
> co-maintainers.
Agree.
> 3. Abolish maintainership entirely.
This would be a mess, as you acknowledged.
> 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
> decision.
>
> 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).
No randomness please. Probably all bodies in Debian are either elected
or appointed (by previously elected bodies). We all know that there are
DD with a known bad track at mediations which would be totally unfit for
such a role.
> 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.
In some part this already happens within the MIA team; but so often
mediation just fail simply due to lack of communication by one part
(i.e. we can't even mediate!)
> If the mediation does not result in satisfaction, a DD complainant
> would send an email to a robot, giving the names and addresses of
> co-complainants.
>
> 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
> themselves.
>
> 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.
This sounds a nicely cut idea to me, except for the randomness above.
> [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.
Fear of retaliation in such a place is IMHO everything but justified.
Or at least it shouldn't be...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
[toc] | [prev] | [next] | [standalone]
| From | Sean Whitton <spwhitton@spwhitton.name> |
|---|---|
| Date | 2016-12-01 18:30 +0100 |
| Message-ID | <sJDlf-7gi-19@gated-at.bofh.it> |
| In reply to | #8870 |
[Multipart message — attachments visible in raw view] — view raw
Hello, On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote: > 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 > replaced. > > 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 > will. Let me add that this can be a big turn-off for potential new contributors who are looking for a niche to fill in Debian. Oh, I use that package, there are some annoying packaging bugs, it could do with some patching and cleaning up -- but there seems to be no way to make it happen. > 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. We're certainly not politically ready, but it's worth noting that there are advantages to sole maintainership. A sense of responsibility for a package can motivate people to polish the package to a higher standard because it has their name on it. But this is a side discussion. > 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 > decision. > > But I would like to make a more radical suggestion. We should make > these decision by juries, rather than committee. Thank you for taking the time to come up with this suggestion. On Thu, Dec 01, 2016 at 05:18:32PM +0100, Mattia Rizzolo wrote: > No randomness please. Probably all bodies in Debian are either elected > or appointed (by previously elected bodies). We all know that there are > DD with a known bad track at mediations which would be totally unfit for > such a role. Although I don't personally know of any such DDs, I agree that random selection sounds like a bad idea. DDs who don't want to be involved in this sort of work would feel under some obligation to respond, even if they know they're not really suited for it or feel that they need to focus their time into some of their own maintenance work, such as before/during a freeze. > > [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. > > Fear of retaliation in such a place is IMHO everything but justified. > Or at least it shouldn't be... This is a big issue for non-DDs, who are very often the people who want to take on these abandoned packages. It's not so much retaliation, but the prospect of looking like an usurper or insubordinator, which could make other DDs wary of sponsoring their uploads. -- Sean Whitton
[toc] | [prev] | [next] | [standalone]
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-01 19:00 +0100 |
| Message-ID | <sJDOi-7Cs-25@gated-at.bofh.it> |
| In reply to | #8871 |
Sean Whitton writes ("Re: Replace the TC power to depose maintainers"):
> Although I don't personally know of any such DDs, I agree that random
> selection sounds like a bad idea. DDs who don't want to be involved in
> this sort of work would feel under some obligation to respond, even if
> they know they're not really suited for it or feel that they need to
> focus their time into some of their own maintenance work, such as
> before/during a freeze.
I think there should be a way to opt out. (Unlike with jury service
in a common law criminal trial.)
So when a jury is needed, the robot would pick 10 random DDs and email
them an offer to participate. Each potential juror would get a few
days[1] to accept/decline. The robot would keep emailing more people
until it got a panel of 10 acceptances.
[1] This should be a short period both to keep the whole duration of
the uncertainty and pain short, but also to end up with jurors who are
around right now.
I think it would be best not to tell jurors, before the jury is
empanelled, what package is in dispute. (They might be able to tell
anyway.)
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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-01 18:50 +0100 |
| Message-ID | <sJDEB-7vD-3@gated-at.bofh.it> |
| In reply to | #8870 |
Mattia Rizzolo writes ("Re: Replace the TC power to depose maintainers"):
> We have a very similar case within the MIA team [...]
Thanks, yes, I remember reading about that. I think less-severe but
still very bad situations are probably more common :-/.
> > 2. Provide a new process for deposing a maintainer, or appointing
> > co-maintainers.
>
> Agree.
Great.
> > For each such dispute, we should pick a panel of randomly chosen DDs,
> > and have them decide (with a time limit).
>
> No randomness please. Probably all bodies in Debian are either elected
> or appointed (by previously elected bodies). We all know that there are
> DD with a known bad track at mediations which would be totally unfit for
> such a role.
By the time it has come to selecting a jury, I think the time for
mediation has probably ended. At the very least by invoking a formal
process , the complainants have significantly burned their bridges.
I agree that there are DDs who are totally unfit for a role on such a
jury. But that is why juries are a panel, rather than an individual.
I think we have few enough unsuitable DDs that the risk of a jury
panel containing many unsuitable people is quite low.
There are good reasons for selecting from a much bigger pool, rather
than electing or appointing a standing panel:
I want the panel deciding on such a maintainership to be able to
easily identify with complainants as well as maintainers. That means
they ought to be people who have, the rest of the time, less special
authority. (Although of course already DDdom is quite an
authority...)
I would like to have such cases judged by people who don't bring
baggage of their own previous arbitrations or leadership decisions
(outside of maintainership).
I would like the arbitration panel to be as representative of our
whole developer community as possible.
I would to avoid the arbitrators being self-selected: that will select
for people who are forthright, confident and prepared to fight, who
will sometimes have a very different view of the interactions in the
contributor/maintainer power relationship.
> > 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.
>
> This sounds a nicely cut idea to me, except for the randomness above.
How would you choose such a panel ?
I am somewhat uncomfortable with the idea of doing this like the DAM
team. Many of the volunteers we would get would be less than ideal.
The same applies to elections.
Juries are a very good fit for this. Each jury decides a specific
question, relating to specific people, and is then disbanded.
> > [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.
>
> Fear of retaliation in such a place is IMHO everything but justified.
> Or at least it shouldn't be...
If you are a contributor to a package, you're probably also a user,
and you are probably an advanced user perhaps with unusual use cases.
You rely on the package in Debian supporting your use cases.
If you get into a nasty dispute with the maintainer, this is at the
very least going to become more difficult.
Of course fear of retaliation ought never to be justified. But we
know that people with power will often use that power to defend their
own position. Of course people vary and Debian maintainers have in
part been selected for altruism or idealism. But I don't think Debian
package maintainers are so much better people than anyone else that
this isn't a problem.
To avoid seeing bad actions, we should arrange our social structures
so that bad actions are not invited, or not effective. Simply saying
"people should not do bad things" is hopeless.
Or to put it another way: everyone has the capacity for good and evil.
All of us should structure our society - and specifically, we in
Debian should structure our project - to bring the good out of people,
and to discourage the evil. The best principal way to discourage evil
is not to punish it, but simply to make doing good more effective.
Of course this thread is about what to do in situations where that has
failed. But even having an effective response to such failure itself
makes the failure less likely.
Or to put it another way: accountable leaders are better leaders.
Thanks,
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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-01 19:10 +0100 |
| Message-ID | <sJDXY-7Z4-53@gated-at.bofh.it> |
| In reply to | #8870 |
Mattia Rizzolo writes ("Re: Replace the TC power to depose maintainers"):
> We have a very similar case within the MIA team (the willing contributor
> contacted us instead of the TC). The only difference is probably that
> the maintainer sent his NAK to me on IRC instead of in a email, and now
> he is not doing that either). The difference is that on paper we don't
> have the authority to "wrest the package away"; but I can't even mediate
> given that this person is not replying....
This makes me ask:
I envisioned a mediation stage, to try to reach consensus, before
deciding the conflict is irreducible and needs to be settled as such.
Could the MIA team do this ? Would you want to ? It seems like it
would need many of the same skills and there would be considerable
overlap with existing MIA activity.
It would be a role with little hard power but a lot of influence.
Ian.
An aside about mediation:
Mediation and arbitration are very different things.
Mediation is about seeing if facilitated communication can help bridge
the gap, and bring people together. It can be very helpful. However,
mediation is normally not very "justice"-focused: it tries to avoid
saying who is right and wrong.
It is important not to allow mediation to become a barrier to
arbitration, or some other process which is actually prepared to make
judgements. Since without judgement (which is what we have now), the
powerless will always be oppressed by the powerful.
--
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.
[toc] | [prev] | [next] | [standalone]
| From | Mattia Rizzolo <mattia@debian.org> |
|---|---|
| Date | 2016-12-01 19:30 +0100 |
| Message-ID | <sJEhk-8aj-17@gated-at.bofh.it> |
| In reply to | #8874 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 01, 2016 at 06:00:42PM +0000, Ian Jackson wrote:
> I envisioned a mediation stage, to try to reach consensus, before
> deciding the conflict is irreducible and needs to be settled as such.
>
> Could the MIA team do this ? Would you want to ? It seems like it
> would need many of the same skills and there would be considerable
> overlap with existing MIA activity.
>
> It would be a role with little hard power but a lot of influence.
Ideally, the MIA team could do it. Practically, we're a tad overloaded
right now. As you probably know the team has been inactive for some
years, and restarted being active only during spring this year; we ended
up with a bit of a backlog....
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
[toc] | [prev] | [next] | [standalone]
| From | Sheetal Shalini <sheetalsh456@gmail.com> |
|---|---|
| Date | 2016-12-03 11:40 +0100 |
| Message-ID | <sKfTA-8pV-13@gated-at.bofh.it> |
| In reply to | #8870 |
[Multipart message — attachments visible in raw view] — view raw
Hi How do I unsubscribe from the debian project mailing list? On Dec 1, 2016 9:48 PM, "Mattia Rizzolo" <mattia@debian.org> wrote: > On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote: > > 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 > > right. > > Even in this extreme situation the TC has not seen fit to wrest the > > package away from the mainainer's deathgrip. > > We have a very similar case within the MIA team (the willing contributor > contacted us instead of the TC). The only difference is probably that > the maintainer sent his NAK to me on IRC instead of in a email, and now > he is not doing that either). The difference is that on paper we don't > have the authority to "wrest the package away"; but I can't even mediate > given that this person is not replying.... > (this is this case reported in d-d: > https://lists.debian.org/debian-devel/2016/11/msg00320.html ) > > > 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. > > This is silly. We have a issue that really needs resolving. > > > 2. Provide a new process for deposing a maintainer, or appointing > > co-maintainers. > > Agree. > > > 3. Abolish maintainership entirely. > > This would be a mess, as you acknowledged. > > > 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 > > decision. > > > > 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). > > No randomness please. Probably all bodies in Debian are either elected > or appointed (by previously elected bodies). We all know that there are > DD with a known bad track at mediations which would be totally unfit for > such a role. > > > 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. > > In some part this already happens within the MIA team; but so often > mediation just fail simply due to lack of communication by one part > (i.e. we can't even mediate!) > > > If the mediation does not result in satisfaction, a DD complainant > > would send an email to a robot, giving the names and addresses of > > co-complainants. > > > > 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 > > themselves. > > > > 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. > > This sounds a nicely cut idea to me, except for the randomness above. > > > [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. > > Fear of retaliation in such a place is IMHO everything but justified. > Or at least it shouldn't be... > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- >
[toc] | [prev] | [next] | [standalone]
| From | Jérémy Bobbio <lunar@debian.org> |
|---|---|
| Date | 2016-12-03 21:30 +0100 |
| Message-ID | <sKp6y-5Zk-19@gated-at.bofh.it> |
| In reply to | #8870 |
[Multipart message — attachments visible in raw view] — view raw
Mattia Rizzolo:
> On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> > 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
> > decision.
> >
> > 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).
>
> No randomness please. Probably all bodies in Debian are either elected
> or appointed (by previously elected bodies). We all know that there are
> DD with a known bad track at mediations which would be totally unfit for
> such a role.
I think random selection would be a nice idea to try.
Positions of power in Debian probably do not rotate enough for the
health of the project. The recent term limit added to the technical
committee is a move in the right direction, IMHO.
I believe most Debian project members could do well with
responsibilities—and they do when maintaining packages. Million of
people around the world trust us, a “random” body of developers, to take
care of their computers. One of the reason I can think of to explain
this trust is that we have a good set of guidelines of what developers
should be doing. Our users get a pretty consistent experience overall,
even while interacting with different project members.
In my view of Ian's proposal, the randomly selected panel would be given
a set of guidelines on how to make their decisions, a standard process
to come to an agreement, and the ability to consult external parties to
get outside looks.
When we reach the point where arbitration is needed, I'd rather take a
decision that will make some people unhappy for some time rather have no
decision and everyone unhappy forever.
--
Lunar .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
[toc] | [prev] | [next] | [standalone]
| From | Andreas Tille <andreas@an3as.eu> |
|---|---|
| Date | 2016-12-08 16:30 +0100 |
| Message-ID | <sM8NX-7L9-21@gated-at.bofh.it> |
| In reply to | #8900 |
On Sat, Dec 03, 2016 at 05:08:06PM +0100, Jérémy Bobbio wrote:
> > > For each such dispute, we should pick a panel of randomly chosen DDs,
> > > and have them decide (with a time limit).
> >
> > No randomness please. Probably all bodies in Debian are either elected
> > or appointed (by previously elected bodies). We all know that there are
> > DD with a known bad track at mediations which would be totally unfit for
> > such a role.
>
> I think random selection would be a nice idea to try.
+1
I trust my fellow DDs sufficently enough that a random pick of 5 people
would be able to decide about things like the discussed question. The
side effect is that those random people are confronted with problems
they are not yet aware about.
Possibly a staus flag in your maintainer profile: "yes, I'd volunteer to
be in the pool for random picks" might be sensible.
Kind regards
Andreas.
--
http://fam-tille.de
[toc] | [prev] | [next] | [standalone]
| From | Vincent Bernat <bernat@debian.org> |
|---|---|
| Date | 2016-12-01 19:10 +0100 |
| Message-ID | <sJDXZ-7Z4-59@gated-at.bofh.it> |
| In reply to | #8869 |
[Multipart message — attachments visible in raw view] — view raw
❦ 1 décembre 2016 15:46 GMT, Ian Jackson <ijackson@chiark.greenend.org.uk> : > 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 > right. > Even in this extreme situation the TC has not seen fit to wrest the > package away from the mainainer's deathgrip. The process is still ongoing, slow, but still. I would have waited a bit more to see where it is going before complaining of inaction. > 3. Abolish maintainership entirely. IMO, this would be a great option. We could keep an official maintainer or a team to keep someone responsible (but we have many examples where this is not sufficient). But otherwise, anyone should be able to upload any package. Maybe the use of a delayed queue (15 days?) could be mandated for those cases. We could also make the low threshold NMU opt-out instead of opt-in. Any step towards less maintainership would be great. -- The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not. -- Mark Twain
[toc] | [prev] | [next] | [standalone]
| From | Clint Adams <clint@debian.org> |
|---|---|
| Date | 2016-12-01 19:30 +0100 |
| Message-ID | <sJEhk-8aj-13@gated-at.bofh.it> |
| In reply to | #8869 |
On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote: > We should go for "weak code ownership" instead, which *in theory* is > what we already have (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. Also, we don't have good tools[^] that Indeed, and it has apparently even crept into team maintenance such that team members don't touch "other people's" team-maintained packages. > I'm personally convinced that a strong, symbolic act is needed to > actually make weak code ownership a reality in Debian. Abolishing the > Maintainer field all together[*] might be it. Sounds good to me.
[toc] | [prev] | [next] | [standalone]
| From | Mattia Rizzolo <mattia@debian.org> |
|---|---|
| Date | 2016-12-01 19:40 +0100 |
| Message-ID | <sJEr0-8du-33@gated-at.bofh.it> |
| In reply to | #8876 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 01, 2016 at 06:26:28PM +0000, Clint Adams wrote:
> On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote:
> > We should go for "weak code ownership" instead, which *in theory* is
> > what we already have (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. Also, we don't have good tools[^] that
>
> Indeed, and it has apparently even crept into team maintenance such
> that team members don't touch "other people's" team-maintained
> packages.
Fortunately this is true only for few teams (sadly big/"important").
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
[toc] | [prev] | [next] | [standalone]
| From | Stefano Zacchiroli <zack@debian.org> |
|---|---|
| Date | 2016-12-01 19:30 +0100 |
| Message-ID | <sJEhk-8aj-15@gated-at.bofh.it> |
| In reply to | #8869 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote:
> 3. Abolish maintainership entirely.
This is the obviously right solution.
Everything else would be a temporary work-around to inefficiencies and
bugs introduced by the existence of explicit maintainership.
With explicit maintainership Debian is ignoring well-known software
engineering best practices, and most notably the fact that "strong code
ownership" is bad and invariably gets in the way of effective
collaborative development.
We should go for "weak code ownership" instead, which *in theory* is
what we already have (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. Also, we don't have good tools[^] that
make it trivial to integrate back changes that have been NMUed by
others; again, getting in the way of efficient collaboration.
I'm personally convinced that a strong, symbolic act is needed to
actually make weak code ownership a reality in Debian. Abolishing the
Maintainer field all together[*] might be it.
Revolutionary yours,
Cheers.
[^] well, we have dgit, but AFAICT is not really popular yet
[*] together with making sure that any DD can commit to any public repo
on alioth
--
Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
[toc] | [prev] | [next] | [standalone]
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-02 12:50 +0100 |
| Message-ID | <sJUvM-3hJ-13@gated-at.bofh.it> |
| In reply to | #8878 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer <josch@debian.org> |
|---|---|
| Date | 2016-12-02 13:40 +0100 |
| Message-ID | <sJVia-3Rc-13@gated-at.bofh.it> |
| In reply to | #8881 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
Quoting Ian Jackson (2016-12-02 12:43:52)
> 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.
are you talking about technical disagreements? Isn't that what the TC is for?
In a world without maintainership and multiple people having different ideas
about a technical problem concerning a package, if discussions between them
have lead to no conclusion, would not the TC have the last word about what is
best for the distribution as a whole?
> Otherwise it really will be chaos, with people uploading contra-reverts of
> each others' reverts.
Personally, I doubt that this would happen. In a world without maintainership,
I'd expect anybody doing an upload to do it with the best interest of the
distribution as a whole at heart. If the content of the upload goes against
what other people had in mind, then I'd expect them to discuss and find a
solution. I would not expect the result to be multiple counter-reverting
uploads from the involved parties. That'd just be rude.
> If we simply remove maintainership and say "do as you like" we are actually
> encouraging such hostile behaviour.
I see it differently. If we remove maintainership, then we are telling our
fellow developers that we trust them with the power they wield. So I see saying
"do as you like" not as an encouragement of hostility but as an encouragement
of mutual help and progress.
> 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.
I believe the same. You are making my argument. :)
> Ownership supports an emotional connection with the work which I think is
> very valuable in a project with many volunteers.
I don't think the emotional connection is lost without the Maintainer field.
The uploader's name will still be in debian/changelog. It will maybe be in the
Uploaders field. It might also be in the dgit history. The "ownership" I feel
by having my name attached somewhere is not lost by allowing more people than
myself to upload.
> Of course there are downsides, but most maintainers - even most sole
> maintainers - in Debian manage their packages well.
I think the same. I think this is the reason why I think that abolishing
maintainership could work well: because the majority of us is doing excellent
work. I believe they will continue to do so whether or not they are given more
privileges over other's packages. In fact, I think that just because most of us
manage our packages well, we'll see an increase in package quality.
It was argued before that if a package is for example team-maintained then that
might mean that because there is no single name attached, nobody feels
responsible to fix bugs in that package and thus a team-maintained package
might loose quality. I don't think that this is the right causality. Sure,
packages are less maintained if nobody cares for them but I don't think that
the "caring" for packages automatically increases by having one's name in the
Maintainer field.
Personally, I don't care for my packages because I have my name in that field
but because I love the software, I love to get more and more acquainted with
the ins and outs of all the technical details the package offers. Because I
love the satisfaction of squashing lintian warnings. Because I love to make
uploads that close lots of bugs. Because I like the satisfaction I get by
knowing that my work just made somebody else's life better. My name will be in
the changelog entries and in the emails I write to the bts. I don't think that
I will take any different amount of care of the packages that currently have me
in the Maintainer or Uploader field if we abolish the former.
> 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 I don't think that people will become different if we don't have the
concept of maintainership anymore. They will still be the same people and take
great care of the software that they are interested in.
> (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.
Same here. That's why I agree with Stefano.
> But of course not everyone can be perfect all the time.
Personally, I put myself into the LowThresholdNmu list exactly because I know I
am not either. If you care about my package and you fixed a problem that I am
unable to fix (either because of lack of time or technical expertise) - please
do an upload! It will safe me time and make me happy if you do.
If your upload breaks something or reverts something that was intentionally put
there by me, then apparently I failed at documenting my changes properly or
adding an autopkgtest. I'd say yet another advantage of encouraging
collaboration through abolishment of the maintainership is, that when I then
would change something in the packaging, I would have an even higher incentive
to document my changes or add tests for them. Something that we really should
do more often (think of all our downstreams that use our work) and are not much
encouraged to do right now because it will always be the same person doing the
packaging and upload.
So none of us being perfect all the time - I'd again put this as an argument
for abolishing maintainership entirely.
> 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 don't think that the main argument for abolishing maintainership is because
of a small number of hard cases. Instead, I think it's because it makes
managing a large number of easy cases much simpler.
> 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.
I am totally with you here. I'd just go a step further as well while we're at
it. :)
Maybe I'm too naive. If I am, could anybody speak up who thinks that they would
take less care of their packages if there is no strict maintainership anymore?
> > 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.
Could you elaborate? I don't find docs on that. And so far I only read about
doing an NMU for a package that uses dgit and not what happens from the side of
the maintainer of that package.
Thanks!
cheers, josch
[toc] | [prev] | [next] | [standalone]
| From | Ian Jackson <ijackson@chiark.greenend.org.uk> |
|---|---|
| Date | 2016-12-02 14:00 +0100 |
| Message-ID | <sJVBv-3XH-5@gated-at.bofh.it> |
| In reply to | #8883 |
Johannes Schauer writes ("Re: Replace the TC power to depose maintainers"):
> Quoting Ian Jackson (2016-12-02 12:43:52)
> > 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.
>
> are you talking about technical disagreements?
I'm talking about any disagreements, including technical ones, yes.
> Isn't that what the TC is for? In a world without maintainership
> and multiple people having different ideas about a technical problem
> concerning a package, if discussions between them have lead to no
> conclusion, would not the TC have the last word about what is best
> for the distribution as a whole?
That would be nice, wouldn't it. In practice, however, the TC is
rarely capable of making a decision without agonising for months.
What will people do while the TC deliberates ?
Also, the TC would rapidly become overloaded if every technical
disagreement in the whole project had to be referred to them, because
there was no other lesser authority.
> I'd expect anybody doing an upload to do it with the best interest of the
> distribution as a whole at heart. If the content of the upload goes against
> what other people had in mind, then I'd expect them to discuss and find a
> solution. I would not expect the result to be multiple counter-reverting
> uploads from the involved parties. That'd just be rude.
The problem with this approach is that it strongly encourages the
creation of `facts on the ground' which it would be `rude' to revert.
I think if we were to abolish the institution of maintainership.
I'm afraid I really struggle to see what principle you and Stefano are
suggesting should replace maintainership as the prima faciae answer to
a disagreement.
"Don't be rude" is all very well, but we know that people have
different ideas about what is rude and what is not. I worry that we
would encourage people to put their own idea about what is rude into
practice...
"Good fences make good neighbours". Or, to put it another way, social
interactions work well when everyone has a shared understanding of the
norms. The basic norms, particularly about who has authority for
which actions, need to be clear and fairly objective.
Right now our norm is maintainership. I think it is too strong and we
should weaken it.
What concrete and objective norms do you want to replace it with ?
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.
[toc] | [prev] | [next] | [standalone]
| From | Adam Borowski <kilobyte@angband.pl> |
|---|---|
| Date | 2016-12-02 16:10 +0100 |
| Message-ID | <sJXDj-5uh-5@gated-at.bofh.it> |
| In reply to | #8883 |
On Fri, Dec 02, 2016 at 01:32:40PM +0100, Johannes Schauer wrote: > Quoting Ian Jackson (2016-12-02 12:43:52) > > Otherwise it really will be chaos, with people uploading contra-reverts of > > each others' reverts. > > Personally, I doubt that this would happen. In a world without maintainership, > I'd expect anybody doing an upload to do it with the best interest of the > distribution as a whole at heart. If the content of the upload goes against > what other people had in mind, then I'd expect them to discuss and find a > solution. I would not expect the result to be multiple counter-reverting > uploads from the involved parties. That'd just be rude. So, let's make an experiment: declare the piece of d-i that decides what init system to install free-for-all to change. Assuming everyone does so only with a honest belief it's for the good of the distribution and users. Or, let's take a look at some projects that allow everyone to make a change. Like, Wikipedia. Let's disregard trolls and vandals, and look only at editors who seem to truly believe what edits are for the better. Multiple counter-reverting is a rule rather than an exception. Or, a personal account: I used to be deeply involved in Crawl's upstream: just a game but I've put way too much effort there. It has a decent-sized active devteam, 10+ commits per day -- yet most months around 40% were mine. All devs with push rights are equal (there's also a number of contributors who send patches to official devs). Enter a dev who only quite recently got push access. One day, he merged a pile of commits that added a bunch of features with quite poor design and abysmal code quality, without putting that into a branch first or discussing on usual dev channels (he merely mentioned it on an equivalent of debian-user which few devs read). That merge also deleted and superseded a large project I had actively worked on at the time. What could I do? My options were to put my weight and mass-revert the whole push (with big save compat issues, especially as another unrelated (proper) big merge also happened hours later), or avoid the conflict by quitting. I did the latter. But, quitting coding a game that you can do without is a lot easier than quitting something you use extensively. Thus, sorry, but a cooperative free-for-all project with everyone being equal just doesn't work past a minimal scale. You need either a separation of rights or some sort of management. Meow! -- The bill declaring Jesus as the King of Poland fails to specify whether the addition is at the top or end of the list of kings. What should the historians do?
[toc] | [prev] | [next] | [standalone]
| From | Iustin Pop <iustin@debian.org> |
|---|---|
| Date | 2016-12-02 20:40 +0100 |
| Message-ID | <sK1QB-7Z6-15@gated-at.bofh.it> |
| In reply to | #8883 |
[Multipart message — attachments visible in raw view] — view raw
On 2016-12-02 13:32:40, Johannes Schauer wrote: > Quoting Ian Jackson (2016-12-02 12:43:52) > > Otherwise it really will be chaos, with people uploading contra-reverts of > > each others' reverts. > > Personally, I doubt that this would happen. In a world without maintainership, > I'd expect anybody doing an upload to do it with the best interest of the > distribution as a whole at heart. If the content of the upload goes against > what other people had in mind, then I'd expect them to discuss and find a > solution. I would not expect the result to be multiple counter-reverting > uploads from the involved parties. That'd just be rude. I applaud your trust in people, but my life experience tells me this will only work for a while before it fails, usually in an ugly way. Let's look again at the situation that sparked the original post: a maintainer that, honestly, behaves in a rude way by not actually taking care of the package and ignores users. This is the smallest way of "being rude". If humans were logical and devoid of emotions, it would work. But even best intentions fail in face of pressure, stress, competition, or simply time. regards, iustin
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2016-12-02 13:20 +0100 |
| Message-ID | <sJUYN-3L6-5@gated-at.bofh.it> |
| In reply to | #8878 |
[Multipart message — attachments visible in raw view] — view raw
Hi, I'm just commenting on this single issue (and aspect of it…) here+now… On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote: > On Thu, Dec 01, 2016 at 03:46:05PM +0000, Ian Jackson wrote: > > 3. Abolish maintainership entirely. > This is the obviously right solution. while I can see where you are coming from and where you want us to go, (and while I like the direction…) I'm not sure such a move would be beneficial, because of unintended consequences: motivation. being able to say "I'm the maintainer of $foo" is a *great* motivation for many. Taking this away *might* cause a lot more harm that gain. -- cheers, Holger
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | linux.debian.project
csiph-web