Hi How do I unsubscribe from the debian project mailing list?
On Dec 1, 2016 9:48 PM, "Mattia Rizzolo" <mat...@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 `- >