Re: Replace the TC power to depose maintainers
]] Ian Jackson
There's no need to Cc me on replies, I'm subscribed already.
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Because I generally find it's generally the wrong tool for the job. If
> > I can come up with a good explanation for why somebody should take a
> > particular course of action (which I need before I'm willing to override
> > anybody), and I take the time to explain it to them and discuss with
> > them, I find we usually end up agreeing.
>
> That is of course mostly true of disagreements.
>
> But it is not mostly true of problems which come to the TC.
>
> Of course sometimes the TC will find that getting people to explain
> themselves clearly will cause the dispute to evaporate. I remember
> that happening about twice during my term. But it's easy to tell
> when this happens because both parties go away happy and say they
> don't need the TC's help any more.
That's not my experience. They'll go away grumbling because they both
had to make some sort of concession(s). The goal of the current dispute
isn't to get global a new maintainer. It's to ensure the package is of
as good quality in Stretch and beyond. This is balanced by the goal of
not making too many people too sad or annoyed, not taking on lots of
technical debt or crazy design decision and so on.
> > The goal is not to end up with a new maintainer. Deposing a maintainer
> > or overriding them is sometimes a necessary evil, but it's never my
> > first option.
>
> Surely the goal should be to make Debian as good a social and
> technical space as possible.
I didn't say what the goal was, I pointed out what it was not.
> If the maintainer is exercising poor leadership - poor enough that
> someone has risked coming to the TC with it - then that goal is best
> served by replacing them.
Based on that argument, the TC should just rubberstamp all appeals and
always grant them, which is surely not what you mean. Also what ScottK
writes about being «on trial» (which is what it feels like) as quite
uncomfortable for the maintainer.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> Lars Wirzenius
> > > I suggest a lighter approach than a GR for eroding the strong package
> > > ownership further is to start another page, "LowThresholdHijack" or
> > > something, listing maintainers who are OK if someone hijacks their
> > > package if the maintainer isn't taking good care of it. Would anyone
> > > else than I put themselves on that new page? (If you would, start the
> > > page on the wiki and announce it on this thread, and I'll add myself.)
> >
> > A similar proposal: Have a way of declaring the package to be under
> > collective maintenance (put it under collab-maint on alioth +
> > Maintainer: collect...@debian.org or somesuch?) That'd move closer to a
> > model where individuals don't own that particular package.
>
> This is all very well and good, but frankly, Lars (and the others in
> this conversation) are not the problem. The problem maintainers won't
> put themselves on a LowThresholdAdoption list either.
>
> We already have ways of dealing with maintainers who are simply
> absent or busy, and not actively resisting. Our processes for that
> are rather cumbersome but it is possible to use them effectively.
>
> What we lack is a way of dealing with maintainers who are determined
> not to lose control of their packages. (And I do mean "control".)
I believe that cultural change can happen through collective action on
an individual level, rather than sweeping regulation and legislation.
The culture around NMUs has changed _immensely_ in the years I've been
involved in the project. Nowadays, they're a pretty routine matter (as
an example, look at the conflict over global where the petitioners have
NMUed a newer version into experimental where this isn't really that big
a deal).
I believe our view of maintainership can change similarly if enough
people say «here are the keys to the kingd^Wpackage, please be
considerate», even for the packages which are not collectivised.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
On Monday, December 05, 2016 11:18:41 PM Ian Jackson wrote:
> Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> > Nonsense. There's no risk for a non-maintainer to come to the TC.
>
> A non-maintainer who comes to the TC:
>
> * Is very likely to find that already unpleasant situation, gets
>emotionally worse, at least temporarily;
>
> * Is probably interested in the package in question, and so risks
>their future contributions being devalued or ignored;
>
> * Is probably an advanced user of the package and may be dependent on
>the package (to some degree or other) continuing to support their
>use cases rather than the maintainer letting them rot or even
>sabotaging them;
>
> * Is likely to worry that they will gain enemies.
>
> These are distinctly nontrivial risks. Most of the risks are social
> in some sense. Some of them are practical. They will put off most
> petitioners, given that the likelihood of the TC escalation being
> useful to them is very small.
Having been involved in one of these things even as a maintainer of a package
that was not directly the target of the request to the TC was extremely
trying. It was by a large margin the second most unpleasant and stressful
free software experience I've had even though the TC, in the end, supported
the existing maintainers.
If it came up again, I'd probably just orphan the package immediately rather
than deal with the process again. That's how awful it is from the side you
claim is all empowered. The non-maintainer risks are trivial in comparison to
the maintainer who risks having their volunteer work for Debian thrown away
and the virtual certainty that they were not going to be able to contribute
any more to a package they thought was important enough to put time and
effort into.
I don't expect you to agree, but if anything, I see all the advantage with the
non-maintainers. I'm glad the TC has my back (and I'm sure if I screw
something up badly enough, they'll help me see it).
Scott K
Re: Replace the TC power to depose maintainers
Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> Nonsense. There's no risk for a non-maintainer to come to the TC.
A non-maintainer who comes to the TC:
* Is very likely to find that already unpleasant situation, gets
emotionally worse, at least temporarily;
* Is probably interested in the package in question, and so risks
their future contributions being devalued or ignored;
* Is probably an advanced user of the package and may be dependent on
the package (to some degree or other) continuing to support their
use cases rather than the maintainer letting them rot or even
sabotaging them;
* Is likely to worry that they will gain enemies.
These are distinctly nontrivial risks. Most of the risks are social
in some sense. Some of them are practical. They will put off most
petitioners, given that the likelihood of the TC escalation being
useful to them is very small.
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
On Monday, December 05, 2016 10:02:02 PM Ian Jackson wrote:
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Because I generally find it's generally the wrong tool for the job. If
> > I can come up with a good explanation for why somebody should take a
> > particular course of action (which I need before I'm willing to override
> > anybody), and I take the time to explain it to them and discuss with
> > them, I find we usually end up agreeing.
>
> That is of course mostly true of disagreements.
>
> But it is not mostly true of problems which come to the TC.
>
> Of course sometimes the TC will find that getting people to explain
> themselves clearly will cause the dispute to evaporate. I remember
> that happening about twice during my term. But it's easy to tell
> when this happens because both parties go away happy and say they
> don't need the TC's help any more.
>
> > The goal is not to end up with a new maintainer. Deposing a maintainer
> > or overriding them is sometimes a necessary evil, but it's never my
> > first option.
>
> Surely the goal should be to make Debian as good a social and
> technical space as possible.
>
> If the maintainer is exercising poor leadership - poor enough that
> someone has risked coming to the TC with it - then that goal is best
> served by replacing them.
Nonsense. There's no risk for a non-maintainer to come to the TC. Worst case
scenario for the non-maintainer is the status quo. The maintainer, on the
other hand, has everything to lose and nothing to gain.
The one time I was peripherally involved in one of these it was long, painful,
and no one got what they wanted, but some things did change and Debian is the
better for the changes (I think they would have happened without the TC
escalation, but that's a counter factual that can't be proven).
In my admittedly limited experience, the worst possible thing the TC could
have done was make a rapid decision.
Scott K
Re: Replace the TC power to depose maintainers
On 2016-12-05 20:57, Philip Hands wrote: > Tollef Fog Heen writes: >> ]] Ian Jackson >>> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >>> weeks during which members of the TC have been prevaricating. >> What are you accusing the TC of lying about? > I think that British English has drifted into using that as a synonym > for procrastinate while American English seems to have stuck to its > earlier meaning (judging by the online dictionary entries I see). There has evidently been drift in both languages. The current full Oxford English Dictionary lists only two senses (when used as an intransitive verb) as non-obsolete: a. To deviate from straightforwardness; to speak or act in an evasive way; to quibble, equivocate. (with citations back to 1623) b. To behave evasively or indecisively so as to delay action; to procrastinate. (with citations back to 1854) It says that the second is "now the usual sense". I can find some American dictionaries which strengthen sense 'a' to include "deliberately mislead" or even "lie", but that is not standard British usage. -M-
Re: Replace the TC power to depose maintainers [and 1 more messages]
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
Lars Wirzenius
> > I suggest a lighter approach than a GR for eroding the strong package
> > ownership further is to start another page, "LowThresholdHijack" or
> > something, listing maintainers who are OK if someone hijacks their
> > package if the maintainer isn't taking good care of it. Would anyone
> > else than I put themselves on that new page? (If you would, start the
> > page on the wiki and announce it on this thread, and I'll add myself.)
>
> A similar proposal: Have a way of declaring the package to be under
> collective maintenance (put it under collab-maint on alioth +
> Maintainer: collect...@debian.org or somesuch?) That'd move closer to a
> model where individuals don't own that particular package.
This is all very well and good, but frankly, Lars (and the others in
this conversation) are not the problem. The problem maintainers won't
put themselves on a LowThresholdAdoption list either.
We already have ways of dealing with maintainers who are simply
absent or busy, and not actively resisting. Our processes for that
are rather cumbersome but it is possible to use them effectively.
What we lack is a way of dealing with maintainers who are determined
not to lose control of their packages. (And I do mean "control".)
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> Because I generally find it's generally the wrong tool for the job. If
> I can come up with a good explanation for why somebody should take a
> particular course of action (which I need before I'm willing to override
> anybody), and I take the time to explain it to them and discuss with
> them, I find we usually end up agreeing.
That is of course mostly true of disagreements.
But it is not mostly true of problems which come to the TC.
Of course sometimes the TC will find that getting people to explain
themselves clearly will cause the dispute to evaporate. I remember
that happening about twice during my term. But it's easy to tell
when this happens because both parties go away happy and say they
don't need the TC's help any more.
> The goal is not to end up with a new maintainer. Deposing a maintainer
> or overriding them is sometimes a necessary evil, but it's never my
> first option.
Surely the goal should be to make Debian as good a social and
technical space as possible.
If the maintainer is exercising poor leadership - poor enough that
someone has risked coming to the TC with it - then that goal is best
served by replacing them.
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> They might want to consult a dictionary then,
I.
Chambers English Dictionary (1994 edition, which is what I have):
prevaricate (vi)
to avoid stating the truth or coming directly to the point;
to quibble.
[And a bunch of other meanings labelled `(obs)'.]
II.
You're a linguistic prescriptivist ?
III.
Anyway, I have explained what I meant. I apologise for giving offence
by using a word that American dictionaries think means something much
more critical than I intended.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Tollef Fog Heen writes: > ]] Philip Hands > >> Tollef Fog Heen writes: >> >> > ]] Ian Jackson >> > >> >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >> >> weeks during which members of the TC have been prevaricating. >> > >> > What are you accusing the TC of lying about? >> >> I think that British English has drifted into using that as a synonym >> for procrastinate while American English seems to have stuck to its >> earlier meaning (judging by the online dictionary entries I see). > > That doesn't match the reading of the Cambridge dictionary: > http://dictionary.cambridge.org/dictionary/english/prevaricate > > prevaricate > verb [ I ] UK /prɪˈvær.ɪ.keɪt/ US /prɪˈver.ə.keɪt/ formal > > to avoid telling the truth or saying exactly what you think: > > Or the Oxford dictionary, > https://en.oxforddictionaries.com/definition/prevaricate: > > prevaricate > VERB > > [NO OBJECT] > Speak or act in an evasive way: > >> I certainly didn't (and still wouldn't) assume that Ian was accusing >> anyone of lying here. > > Given his later apology, I'd assume so as well, but as a native speaker > of English, Ian should really know better than using the term in the > first place. Jolly interesting. It looks like I'll have to add the misuse of that to my list of pedantic pet hates, which is currently topped by 'epicentre' and 'decimate' ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
]] Philip Hands > Tollef Fog Heen writes: > > > ]] Ian Jackson > > > >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > >> weeks during which members of the TC have been prevaricating. > > > > What are you accusing the TC of lying about? > > I think that British English has drifted into using that as a synonym > for procrastinate while American English seems to have stuck to its > earlier meaning (judging by the online dictionary entries I see). That doesn't match the reading of the Cambridge dictionary: http://dictionary.cambridge.org/dictionary/english/prevaricate prevaricate verb [ I ] UK /prɪˈvær.ɪ.keɪt/ US /prɪˈver.ə.keɪt/ formal to avoid telling the truth or saying exactly what you think: Or the Oxford dictionary, https://en.oxforddictionaries.com/definition/prevaricate: prevaricate VERB [NO OBJECT] Speak or act in an evasive way: > I certainly didn't (and still wouldn't) assume that Ian was accusing > anyone of lying here. Given his later apology, I'd assume so as well, but as a native speaker of English, Ian should really know better than using the term in the first place. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
Tollef Fog Heen writes: > ]] Ian Jackson > >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >> weeks during which members of the TC have been prevaricating. > > What are you accusing the TC of lying about? I think that British English has drifted into using that as a synonym for procrastinate while American English seems to have stuck to its earlier meaning (judging by the online dictionary entries I see). I certainly didn't (and still wouldn't) assume that Ian was accusing anyone of lying here. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
]] Ian Jackson
> Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose
> maintainers"):
> > Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > > 6+ weeks during which members of the TC have been prevaricating.
> >
> > I had to lookup prevaricate in a dictionary:
> > > to speak falsely or misleadingly; deliberately misstate or create an
> > > incorrect impression
> > > to deviate from the truth
> >
> > This is not helping, really. Please tone down.
>
> That's not what meant by "prevaricate". I asked #chiark about the
> meaning of the word and they said:
They might want to consult a dictionary then,
http://www.dictionary.com/browse/prevaricate:
verb (used without object), prevaricated, prevaricating.
1. to speak falsely or misleadingly; deliberately misstate or create
an incorrect impression; lie.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > weeks during which members of the TC have been prevaricating. What are you accusing the TC of lying about? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > Imagine the roles were replaced. Imagine the actual petitioners (P > and W, for the same of argument) were the current maintainers, and the > actual current maintainer (R) were a petitioner saying "please make me > the maintainer". Would the TC would spend months debating before > dismissing such a manifestly unfounded petition ? That's a very hypothetical question which is hard to answer without more context of what P and W had done lately in terms of maintaining the package. > Can you explain why the TC is so reluctant to depose or overrule > maintainers ? Because I generally find it's generally the wrong tool for the job. If I can come up with a good explanation for why somebody should take a particular course of action (which I need before I'm willing to override anybody), and I take the time to explain it to them and discuss with them, I find we usually end up agreeing. The goal is not to end up with a new maintainer. Deposing a maintainer or overriding them is sometimes a necessary evil, but it's never my first option. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Lars Wirzenius > I suggest a lighter approach than a GR for eroding the strong package > ownership further is to start another page, "LowThresholdHijack" or > something, listing maintainers who are OK if someone hijacks their > package if the maintainer isn't taking good care of it. Would anyone > else than I put themselves on that new page? (If you would, start the > page on the wiki and announce it on this thread, and I'll add myself.) A similar proposal: Have a way of declaring the package to be under collective maintenance (put it under collab-maint on alioth + Maintainer: collect...@debian.org or somesuch?) That'd move closer to a model where individuals don't own that particular package. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote: > I have just created the page: > > https://wiki.debian.org/LowThresholdAdoption > > and added myself to the list. I've added myself to the list. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
Dear all El 05/12/16 a las 19:13, Lars Wirzenius escribió: > We've had the "strong package ownership" concept be a problem in > various ways. Many years ago people were afraid of making NMUs to fix > bugs, even RC bugs, and I started the > https://wiki.debian.org/LowThresholdNmu page. It's got over 300 > maintainers now, and NMUs are quite normal, though I suspect zack's > NMU campaigning helped more. > > I suggest a lighter approach than a GR for eroding the strong package > ownership further is to start another page, "LowThresholdHijack" or > something, listing maintainers who are OK if someone hijacks their > package if the maintainer isn't taking good care of it. I like this idea, although I felt confused about the term. I asked Lars about it in IRC, posting the conversation with his permission: Hi! I'm not sure about what do you mean about hijack, isn't the same as "adoption"? I mean, a maintainer sends a RFA or Orphans a package when she cannot care about it, this is the same, but the initial movement made by a different DD. Isn't it? pretty much. hijack has a stronger connotation where it's done against the current maintainer's wishes, but my proposed list would remove that connotation possibly hijack is the wrong word I don't know if there is a word in English for when the state decides to take apart children from bad (no caring) parents, in Spanish it's "quitar la custodia". That would be the word I would use. If there is not, "adoption", simply, to encourage people to sign in the list. agreed Or maybr just a list of "cat model package maintainers" http://www.trueelena.org/computers/articles/the_cat_model_of_package_ownership.html LowThresholdAdoption maybe? Yes feel free to copy this discussion to the email thread :) Thanks. Will do. Would anyone > else than I put themselves on that new page? (If you would, start the > page on the wiki and announce it on this thread, and I'll add myself.) > I have just created the page: https://wiki.debian.org/LowThresholdAdoption and added myself to the list. I've copied some parts from the LowThresholdNmu wiki page but deleted others (mainly about procedure, because if more people likes this idea, I guess some "procedure" like a NM-RFA should be created? I leave this for the "packaging"(uploading) DDs. I've added myself to the list for one of the tasks I have committed to care in Debian, the coordination of the Spanish translation of www.debian.org. Best regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: Replace the TC power to depose maintainers
Ian Jackson writes:
> Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
>> I still don't understand why the TC is so crushingly slow to conter
>> maintainer power in Debian. As I say in my other emails, a result of
>> the TC's inaction, maintainer power in Debian is nearly unassailable.
>
> Didier, and Phil, now you're in this conversation: can you explain
> this to me ?
I just replied to another of your mails -- in a mail started fairly soon
after you mail, and only just finished because my wife is in bed with a
temperature, both kids are coughing and spluttering, and I too have a
cold, so time's been a bit short today.
Hopefully my reply doesn't seem too much out of sequence -- I've not
been attempting to follow subsequent discussion until I got it sent.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: Replace the TC power to depose maintainers
Ian Jackson writes:
> Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
>> this NOOP,
>
> I'm very surprised to see you say that you think this is a no-op.
>
> ISTM that in the current argument, the TC has given the position of
> the existing maintainer great weight.
>
> Imagine the roles were replaced. Imagine the actual petitioners (P
> and W, for the same of argument) were the current maintainers, and the
> actual current maintainer (R) were a petitioner saying "please make me
> the maintainer". Would the TC would spend months debating before
> dismissing such a manifestly unfounded petition ?
Ah, that's what you mean -- that's not what your GR said though, as far
as I could tell.
The way I read it is that we should not give special status to the
arguments presented based on the maintainer status of the person putting
forward those arguments.
You now appear to be saying that we should not consider maintainership
to be in any sense sticky, and should instead assume that the package is
orphaned when it's presented to the TC, and assign the maintainership as
if we're blind to its history at the end of the process.
Those seem like barely related positions, and the latter is nothing to
do with what you wrote in the draft GR.
> As I've said I genuinely find the TC's behaviour incomprehensible.
> But this is not limited to this TC; all previous TCs have had similar
> issues (from my point of view). As I say the TC members are all smart
> and good people so I don't think the problem can be changed by a
> change of personell. I definitely don't want you to resign.
>
> Can you explain why the TC is so reluctant to depose or overrule
> maintainers ?
I have been pondering this since you raised it.
There is research to show that groups of people tend to express opinions
as a group that are more extreme than the centre of gravity of the
opinions of the individuals.
It seems it happens because people tend to assume that the centre of
opinion is further along whatever spectrum one is talking about than
they are personally, and so adjust their expressed opinions to match,
and thus everyone's perception of the centre drifts further in that
direction.
I wonder if the TC does this in the dimension of something like
reasonableness, patience, politeness, conciliation, or some such
I suspect that if I'd been acting alone in a situation where I was only
answerable to myself that cases would have been dealt with in one
exchange of mails. ;-)
I'm not sure how one might fix that, but it's not going to be by adding
extra rules and metrics that one is expected to measure one's
performance against. That would just add another thing to think about
instead of acting.
Add to that the fact that the individuals involved all tend to be
sporadically busy and the discussion ends up running at the pace of the
person that can give it the least time, which also militates against
decisive action.
Even if the obvious action is to replace the maintainer, that would
always do more good if done instantly than after a pause of months, but
that's pretty-much impossible to achieve via a group of busy volunteers.
Once months have gone by, the situation normally becomes less clear-cut,
because one has already lost the benefit of a snap decision.
I don't think any of that is particularly unique to the TC, and would
equally apply to anything that you might be tempted to replace it with
(unless the replacement were a single individual, or an algorithm).
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
We've had the "strong package ownership" concept be a problem in various ways. Many years ago people were afraid of making NMUs to fix bugs, even RC bugs, and I started the https://wiki.debian.org/LowThresholdNmu page. It's got over 300 maintainers now, and NMUs are quite normal, though I suspect zack's NMU campaigning helped more. I suggest a lighter approach than a GR for eroding the strong package ownership further is to start another page, "LowThresholdHijack" or something, listing maintainers who are OK if someone hijacks their package if the maintainer isn't taking good care of it. Would anyone else than I put themselves on that new page? (If you would, start the page on the wiki and announce it on this thread, and I'll add myself.) -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
Russ Allbery writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
> Ian Jackson writes:
> > The TC has never desposed an existing maintainer, and very rarely even
> > overturned an individual decision.
>
> There is a widespread perception that doing this would frequently cause
> that maintainer to leave Debian. This is quite the mental hurdle to
> overcome,
But what about the contributors who leave Debian because their work is
stymied ? To worry too much that the maintainer will quit Debian is
neither fair nor effective.
It is not fair because worrying more about the emotions of the
existing maintainer, than the other contributors, is privileging the
emotions of the powerful over those of the weak. That is unjust.
It is not effective because it amounts to making life more comfortable
for those who block others, even in the face of advice and criticism.
Conversely we discourage for those who face problems trying to get
work done, and discourage those who do not like to fight (and will go
away and do something else).
So this approach is implicitly selecting contributors for
stubbornness, aggression and even selfishness.
> I think we all agree that this is a bad situation to be in, and we
> should not block other active maintainers because we're afraid that
> we'll demotivate someone who isn't doing a great job anyway. In
> other words, I don't think anyone views the above situation as a
> *feature*. However, it's still psychologically difficult,
Is there a way we can reframe this so that it is about empowering
those who are constructive but powerless, rather than about protecting
the feelings of the powerful ?
> and I don't think it becomes less difficult by ramping up the
> confrontationalness
I certainly don't think "ramping up the confrontationalness" is what I
am trying to do.
Of course by using this case as an example, that's what I'm doing to
this specific case. But the situation of "difficult" maintainers is
hardly unusual. I think there is massive suppressed demand for an
effective way to handle difficult maintainers. We desperately need a
more effective approach.
> I think this is partly what Zack is getting at. If we want to make
> the situation less fraught, and make changing maintainers or
> allowing other people to upload packages a less difficult step to
> make, formalizing this as a remedy in hard cases is less effective
> as just undermining the concept of maintainership *in general*.
I am really scared that without some idea of ownership we will be
playing core wars in the archive. What rules do you propose to
replace maintainership with to prevent this ?
One thing that we /have/ done is made it much easier to transfer
maintainership away from a maintainer who is not realy bothered.
(It's still arguably not easy enough.)
The result is that the remaining cases are _by definition_ the ones
where the maintainer is bothered, and wants to defend their position.
> In other words, I completely agree with you on the problem, but I feel
> like you're tackling it from the wrong end, since hard cases make bad law.
You're saying that _any_ cases of dispute make bad law.
I think your "hard cases" analogy is competely inapposite, actually.
We're not really talking about making caselaw.
I think the reason there are no "easy" cases before the TC is because
the TC is so ineffective and so unlikely to be useful, that you have
to be *really desperate* or *really frustrated* to invoke the TC.
If the TC were swift and decisive, it would be a much more normal
thing. More people would have experience that it wasn't the end of
the world to have to have your argument refereed by someone.
If we really follow through on this "hard cases make bad law"
position, it leads to a conclusion that the TC can never work and
should be abolished and replaced with something entirely different.
I take a different view. We already have ways of handling
maintainership that work well when the maintainer is not too stubborn
or possessive.
We just need a mechanism for dealing with the difficult cases. That
mechanism is supposed to be the TC, which is supposed to decide cases
on the merits.
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers [and 1 more messages]
Ian Jackson writes:
> 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.
There is a widespread perception that doing this would frequently cause
that maintainer to leave Debian. This is quite the mental hurdle to
overcome, and the exhortations to not care about this (the subtext of
"Debian is better without people who would leave because of that") don't
really help. People get their motivations from different sources. It's
hard to figure out how to balance this against the demotivating effects of
an ongoing bad situation.
I know you know all this, but I want to restate it for the record because
it affects heavily how I view this proposal.
I think we all agree that this is a bad situation to be in, and we should
not block other active maintainers because we're afraid that we'll
demotivate someone who isn't doing a great job anyway. In other words, I
don't think anyone views the above situation as a *feature*. However,
it's still psychologically difficult, and I don't think it becomes less
difficult by ramping up the confrontationalness of the hardest cases (the
ones that come before the TC). The semi-paralysis is largely already
because the situation is so fraught, and you're proposing making it even
more fraught.
I think this is partly what Zack is getting at. If we want to make the
situation less fraught, and make changing maintainers or allowing other
people to upload packages a less difficult step to make, formalizing this
as a remedy in hard cases is less effective as just undermining the
concept of maintainership *in general*. This makes all disputes over
maintainership somewhat less fraught by making maintainership less of a
thing that people feel possessive about, which in turn will make the hard
cases easier to handle as well.
In other words, I completely agree with you on the problem, but I feel
like you're tackling it from the wrong end, since hard cases make bad law.
--
Russ Allbery (r...@debian.org)
Re: Replace the TC power to depose maintainers
Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > 6+ weeks during which members of the TC have been prevaricating.
>
> I had to lookup prevaricate in a dictionary:
> > to speak falsely or misleadingly; deliberately misstate or create an
> > incorrect impression
> > to deviate from the truth
>
> This is not helping, really. Please tone down.
That's not what meant by "prevaricate". I asked #chiark about the
meaning of the word and they said:
17:34 What does the channel think "prevaricate" means ?
17:34 to put off, possibly while pretending not to
17:35 avoid a decision or question
17:35 "we'll tell you later"
17:35 like procrastination but for speech
17:35 to waver over a decision and postpone making it.
I certainly didn't mean to suggest dishonesty. Apologies for the
offence.
> Frankly, with the timing, content and tone of your meta-interventions around
> the "recent case" we're talking about, you have just added two more weeks to
> the process. I now took some time to address these meta-concerns, while I
> could have have focused on gathering commitments from the actual and
> prospective maintainers of src:global instead, and drafted a ballot.
The decision to give the package to the prospective new maintainers
could and should have been made 4 weeks ago. It's a complete
no-brainer.
The easy way to address my meta-concerns would have been to
demonstrate them wrong! (Or at least to quickly rob me of this
absolutely excellent example.)
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit : > The bug was filed on the 19th of October. That was nearly 7 weeks > ago. Sure. I'm not saying the TC couldn't be better. > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. I agree with that. > 6+ weeks during which members of the TC have been prevaricating. I had to lookup prevaricate in a dictionary: > to speak falsely or misleadingly; deliberately misstate or create an > incorrect impression > to deviate from the truth This is not helping, really. Please tone down. Frankly, with the timing, content and tone of your meta-interventions around the "recent case" we're talking about, you have just added two more weeks to the process. I now took some time to address these meta-concerns, while I could have have focused on gathering commitments from the actual and prospective maintainers of src:global instead, and drafted a ballot. OdyX
Re: Replace the TC power to depose maintainers
Ian Jackson writes ("Re: Replace the TC power to depose maintainers"):
> I still don't understand why the TC is so crushingly slow to conter
> maintainer power in Debian. As I say in my other emails, a result of
> the TC's inaction, maintainer power in Debian is nearly unassailable.
Didier, and Phil, now you're in this conversation: can you explain
this to me ?
I have a number of theories. Mayber TC members are reluctant to make
_any_ decision for fear of making a mistake. Maybe TC members are
reluctant to act without consensus. Maybe TC members are reluctant to
upset maintainers. Maybe TC members are uncomfortable, as technical
people, exercising hard power, and prefer to persuade. Maybe
something else, which I don't understand.
If I understood _why_ TC members (other than me) behaved this way, it
might be possible to frame a GR where the whole project could indicate
whether they think this is right or wrong.
If I put forward such a GR and lose it, at least I'll know where I
stand. There is no point me trying to push this years-long campaign
to weaken Debian maintainership (originally, by getting the TC to use
its power, but that doesn't seem to be getting much more likely) if
the rest of the project thinks that it is just fine that our
maintainers are almost completely unaccountable.
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> I think you're really jumping the gun here. While the TC is not
> known for acting rapidly, I (would like to) think it is becoming
> better. In the "recent case" you're using as trigger to this very
> discussion [0], although some TC members have already expressed
> opinions (mostly both ways, I feel), the TC hasn't taken a decision
> yet. It therefore feels quite premature to launch a "Replace the TC
> power to depose maintainers" discussion.
The bug was filed on the 19th of October. That was nearly 7 weeks
ago.
That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+
weeks during which members of the TC have been prevaricating.
As I wrote in my message to Phil earlier today:
ISTM that in the current argument, the TC has given the position of
the existing maintainer great weight.
Imagine the roles were replaced. Imagine the actual petitioners (P
and W, for the same of argument) were the current maintainers, and the
actual current maintainer (R) were a petitioner saying "please make me
the maintainer". Would the TC would spend months debating before
dismissing such a manifestly unfounded petition ?
It takes very little time to review the history of this package and
conclude that, regardless of the technical merits of the new upstream:
- the work put in both others over the past years, and blocked
by the maintainer, far outweighs that put in by the maintainer
- the maintainer has failed to communicate adequately
- the maintainer has failed completely in their leadership role
- in fact the maintainer has done /nothing/ but produce stop-energy
As I say, if P and W were already the maintainer, the TC would surely
have not blocked P and W from uploading the new version for weeks
while they carefully considered whether R might have a point about the
defects of the new upstream version.
> You have been on the TC long enough to know how uneasy a TC members' job can
> be; what about letting those are now in charge with some room ?
I have been on the TC long enough to become incredibly frustrated with
the longstanding failure of the TC to challenge the unaccountable
authority of Debian maintainers.
Leaving aside the init systems discussion, I have always found that my
primary emotional difficulty as a TC member has been my
incomprehension at my colleagues' lack of gumption.
Over the years, I have tried calm reasoning; I have tried flowery
rhetoric; I have tried private emails; I have had numerous private
IRL conversations.
I still don't understand why the TC is so crushingly slow to conter
maintainer power in Debian. As I say in my other emails, a result of
the TC's inaction, maintainer power in Debian is nearly unassailable.
Ian.
--
Ian JacksonThese 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.
Re: Replace the TC power to depose maintainers
Le vendredi, 2 décembre 2016, 15.42:58 h CET Ian Jackson a écrit : > Hey, I have an idea that maybe you will support, which takes us much > more in that direction and may reinvigorate our existing processes: > > DRAFT GENERAL RESOLUTION STARTS As a general comment, I am in discomfort with GR proposals which have too much preamble and context as part of the decision. Specifically… > OPTION A > > 1. Our priority is our users and free software. > > 2. Debian maintainership is a position of power and responsibility. > It is an earned position, which arises from work and leadership. > Maintainership should continue so long as the good leadership > continues. These two points should be in an argumentary in favour of the actual GR, and not in the GR text. Having the body of developers "emit" that kind of wording (not that I disagree with it…) opens the door to later interpretations, debate about wording, etc. It's uneeded for a GR to re-state that our priority is our users and free software. We have it a foundation document, and re-stating it out of the blue is doing more harm than good, IMHO. > 3. We give advice to the Technical Committee: Giving "wildcard advice" about maintainership, as output of a discussion triggered by "I think the TC will not decide my way", _before_ the TC is just about to take a decision about maintainership, would (as Phil eloquently put it) imply that the project is not trusting the TC and its members to exercise the powers and duties as defined in the constitution. Would that GR pass, I would most probably resign from the TC. That said… the TC's constitutional mandate _is_ up for discussion, it always was, and should always be. It's entirely fine to discuss how the project wants to distribute its powers and duties internally. But if one wants to address how maintainership is handled, emitting a no-op GR giving advice to the TC members is the wrong hammer for that nail, I think. > 4. The Technical Committee should consider all opinions and options > based on their merits, not based on the authority of the speaker. This wording assumes that the TC currently isn't (same goes for further articles. > OPTION B > > (1-6 as above) > > 7. We amend the Constitution section 6.1(4) to remove the words > "requires a 3:1 majority" and "this requires a 3:1 majority". A GR doing that (amending the constitution to lower the TC majority needed when overruling a developer), and only that, would be a strong message from the project upon the importance it gives to maintainership and developers' decisions. I'm not decided whether I like that specific idea or not, but I certainly feel that such a GR would be much less paternalizing to the TC and its members than any flavour of your Option A. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Replace the TC power to depose maintainers
Le jeudi, 1 décembre 2016, 15.46:05 h CET Ian Jackson a écrit : > 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 think you're really jumping the gun here. While the TC is not known for acting rapidly, I (would like to) think it is becoming better. In the "recent case" you're using as trigger to this very discussion [0], although some TC members have already expressed opinions (mostly both ways, I feel), the TC hasn't taken a decision yet. It therefore feels quite premature to launch a "Replace the TC power to depose maintainers" discussion. By launching the discussion through assuming the TC will not decide how you think is most fit, you are exercising unwarranted pressure on the TC members who will eventually need to take a decision. You have been on the TC long enough to know how uneasy a TC members' job can be; what about letting those are now in charge with some room ? OdyX [0] #841294, for those not following the tech-ctte pseudo-bug or the debian- ctte@l.d.o list signature.asc Description: This is a digitally signed message part.
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 +, 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 JacksonThese 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.
Re: Replace the TC power to depose maintainers
Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> this NOOP,
I'm very surprised to see you say that you think this is a no-op.
ISTM that in the current argument, the TC has given the position of
the existing maintainer great weight.
Imagine the roles were replaced. Imagine the actual petitioners (P
and W, for the same of argument) were the current maintainers, and the
actual current maintainer (R) were a petitioner saying "please make me
the maintainer". Would the TC would spend months debating before
dismissing such a manifestly unfounded petition ?
As I've said I genuinely find the TC's behaviour incomprehensible.
But this is not limited to this TC; all previous TCs have had similar
issues (from my point of view). As I say the TC members are all smart
and good people so I don't think the problem can be changed by a
change of personell. I definitely don't want you to resign.
Can you explain why the TC is so reluctant to depose or overrule
maintainers ?
Ian.
