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  `-
>

Reply via email to