Re: Replace the TC power to depose maintainers [and 1 more messages]

[Tollef Fog Heen]

]] 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 [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".)

Ian.

-- 
Ian Jackson    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.

Re: Replace the TC power to depose maintainers [and 1 more messages]

[Tollef Fog Heen]

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

[Lars Wirzenius]

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]

[Laura Arjona Reina]

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 [and 1 more messages]

[Lars Wirzenius]

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]

[Ian Jackson]

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 Jackson    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.

Re: Replace the TC power to depose maintainers [and 1 more messages]

[Russ Allbery]

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 [and 1 more messages]

[Ian Jackson]

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 Jackson    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.