Re: Replace the TC power to depose maintainers

[Ian Jackson]

Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> > I think the maintainer saw the writing on the wall, so I count this as
> > a successful intervention by the TC.  (I hope the new maintainers will
> > prove me right.)  That there wasn't a formal vote is beside the point.
> 
> I don't consider this case particularly successful.  Regardless of what
> one thinks of the outcome, the process was subpar and had people sniping
> at each other.  I don't think that's how the process ought to look.

Sorry, I evidently failed to be clear enough.  I agree that the
process was bad.  That means that the part of the outcome which is
`how to people feel now' is not good.

The context of my remarks above is precisely Phil's question:

  I wonder which column on your tally sheet you will put this
  outcome.

I meant just that the TC's power was used to depose an obstructive
maintainer.  So this goes in the `TC did intervene' column of Phil's
supposed tally sheet.

> > I still (perhaps, even more so) believe we need to have a better way
> > of dealing with these kind of disputes.
> 
> That I agree with.

We have seen a lot of disagreement here on -project about what shape
such a thing should be.  Do you have any bright ideas ?

Ian.

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

Re: Replace the TC power to depose maintainers

[Tollef Fog Heen]

]] Ian Jackson 

> Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> > Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > > 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.
> > 
> > I wonder which column on your tally sheet you will put this outcome.
> 
> I think the maintainer saw the writing on the wall, so I count this as
> a successful intervention by the TC.  (I hope the new maintainers will
> prove me right.)  That there wasn't a formal vote is beside the point.

I don't consider this case particularly successful.  Regardless of what
one thinks of the outcome, the process was subpar and had people sniping
at each other.  I don't think that's how the process ought to look.

> I still (perhaps, even more so) believe we need to have a better way
> of dealing with these kind of disputes.

That I agree with.

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

Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > 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.
> 
> I wonder which column on your tally sheet you will put this outcome.

I think the maintainer saw the writing on the wall, so I count this as
a successful intervention by the TC.  (I hope the new maintainers will
prove me right.)  That there wasn't a formal vote is beside the point.

> In this particular instance, at least a week of the time spent on this
> mess was devoted to dealing with you -- don't do anything like that again.

FAOD I value your opinion, and it doesn't make me happy to hear that
from you.  I've been thinking about this and will think some more.

I still (perhaps, even more so) believe we need to have a better way
of dealing with these kind of disputes.

Regards,
Ian.

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

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Rhonda D'Vine writes ("Re: Replace the TC power to depose maintainers"):
>  Going towards an abolished maintainership
> area it will make it even less likely such needed communication with the
> people feeling emotionally attached to the package to happen.

This is a very good way of explaining the social reasons for retaining
something like maintainership.

>  It's already at the lower and every now and then that it hurts,

I think if one is very stubborn, and doesn't mind undoing other
people's work, etc., then maintainership is very strong.  If one cares
about doing what much the rest of the project says it wants,
maintainership is often quite weak.

This is not really a good combination.

Ideally maintainership would be strong for the maintainer who doesn't
like to argue much and who is easy to convince of true things, but
weak when used by a stubborn maintainer or one who communicates
poorly.

I have not much of an idea how to do that, but making _sole_
maintainership weaker is perhaps going in that direction.

Ian.

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

Re: Replace the TC power to depose maintainers

[Charles Plessy]

Le Sun, Dec 11, 2016 at 03:00:22PM +0900, Charles Plessy a écrit :
> 
> Dear TC, you have my support, and please feel empowered to require high
> standards from the confronting parties that ask for your decisions, so that
> your task is made easier, for everybody' good.
> 
>  - The TC members should not be asked to read through long threads [...]
>  - Of course, since this requires significant involvement from both parties, 
> [...]
>  - With this guarantee, I think that it would be fair if the TC would give 
> deadlines [...]
>  - Similarly, if some TC members do not have time to get deeply involved [...]
>  - To keep the discussion in clear boundaries, [...]
>  - In general, do not hesitate to be severe with those who play the clock.
>  - Also, I think that the main expectation about the TC is that it will 
> resolve conflicts [...]

Sorry, I forgot one suggestion:

 - I think that it would be totally fair if the TC, based on its task list and
   based on the urgency of the questions that are raised, would sometimes
   decide upfront to leave one case untouched for some weeks or even a copuple 
of
   months, to avoid dispersing its attention on too many problems.  As long as 
the
   decision is not re-postponed, I think that it can be in everybody's best 
interest.

I hope that my comments will not be taken as a lecture on how being better
efficient.  The message is rather that if you already thought about following
that kind of way, don't worry and go for it !

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: Replace the TC power to depose maintainers

[Charles Plessy]

Dear Ian, TC members and everybody,

the discussion about maintainership is interesting, and maybe I will post a
comment later, but I think that the main problem is the speed of the TC to take
its decissions.

And one very important comment that was made in this thread is that the TC
needs wide support from Debian members.  It needs trust and respect.

So I would like to tell my personal opinion here, which I hope is shared by
many other project members:

Dear TC, you have my support, and please feel empowered to require high
standards from the confronting parties that ask for your decisions, so that
your task is made easier, for everybody' good.

 - The TC members should not be asked to read through long threads and dig
   history in the mailing lists.  Instead, each side should maintain a
   synthethic position with a proper rebuttal of the other side's opinions, and
   maintain it up to date.

 - Of course, since this requires significant involvement from both parties, the
   TC has to protect maintainers from deliberate obstructions or attempts to
   suck up their time and demotivate them with TC procedures.   To block that
   kind of "negative energy", the TC should not hesitate to dismiss a complain
   if it is poorly argumented, or if nobody on the complaining side has time
   to follow up.

 - With this guarantee, I think that it would be fair if the TC would give
   deadlines to the conflicting sides to explain their views.  Its closed
   mailing list would be a good tool for negociating the deadlines without
   disclosing personal information. (And of course, in the case of 
non-responsive
   maintainers, it will still be a bad argument if one answers that there is
   enough time to take care of the package, but not enough time to provide 
answers
   to the CTTE in a reasonable delay).

 - Similarly, if some TC members do not have time to get deeply involved
   in a discussion, that is life, and that is one reason why there is a 
committee
   of multiple members.  In the worst case scenario, do not hesitate to skip a
   given vote, I am sure that the project as a whole will not blame you for 
this.
   Rather, we will be grateful that you helped that way to speed up the process.

 - To keep the discussion in clear boundaries, random opinons from third
   parties that are not integrated on one or the other side's argumentation can
   be ignored.  External imput is welcome, but it should be the role of both 
sides
   to adopt it in their argumentation if they think they are important enough.
   Late minute minor comments should not be a blocker either.  Otherwise, there 
is
   never and end and it opens the way to tactical behaviours for delaying
   decisions.

 - In general, do not hesitate to be severe with those who play the clock.

 - Also, I think that the main expectation about the TC is that it will resolve
   conflicts, and in that sense, I would say please do not feel pressure to
   find an even better solution to a problem by yourselves, that would leave
   on your shoulders the pressure for implementation when noboy else volunteers
   for it.  Just unblocking a frozen situation is already great !

Altogether, thanks a lot for your work !

Have a nice Sunday,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: Replace the TC power to depose maintainers

[Philip Hands]

Ian Jackson  writes:

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

I wonder which column on your tally sheet you will put this outcome.

In this particular instance, at least a week of the time spent on this
mess was devoted to dealing with you -- don't do anything like that again.

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

[Rhonda D'Vine]

Hi,

* Johannes Schauer  [2016-12-02 13:40:31 CET]:
> Quoting Holger Levsen (2016-12-02 13:11:05)
> > 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 +, 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.
> 
> Why would this be taken away?

 Because it takes away the need to communicate with the maintainers and
respecting their view on the package and how it develops/is maintained.
It happened more than enough times for me personally in the past years
that people upload non-coordinated and not-communicated fixes that it
annoyed me enough to kill a fair amount of my motivation.  

 I've seen packaging reworks combined with "just a bug fix" also every
now and then and there is a reason for the list of what people shouldn't
do when they upload an NMU.  Going towards an abolished maintainership
area it will make it even less likely such needed communication with the
people feeling emotionally attached to the package to happen.  It's
already at the lower and every now and then that it hurts, and saying
there is no maintainership means that noone has to coordinate with
anyone anymore because ... well, there is no maintainer.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Re: Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers)

[Raphael Hertzog]

On Thu, 08 Dec 2016, Guillem Jover wrote:
> It is not only not obviously right to me, instead it seems obvious
> it carries a set of different problems with it. I feel this carries
> so many assumptions of how the proposers feel about how *they* work
> or might like to work and ignores how *others* do that. :/

I don't think that entirely abolishing maintainership is a good move.
But we should change our process so that by default we have no hard
lockin on most packages.

For packages where the persons doing the work have special requirements,
they should document those requirements in debian/README.maintainers (or
README.contributors).

In that file they could:
- ask to review changes prior to upload (and give some delay in which
  they usually respond)
- define some package-policy to follow (conventions, procedures)
- document upstream related things that are good to know
- explain their plan for the next upstream release wrt to Debian's release
- etc.

Team maintained packages could just add a pointer to the team policy.

With such a system, it makes sense to drop the Maintainer/Uploaders from
the package and have it dynamically generated from persons actually
working on the package.

We don't need a sole maintainer to make decisions, everyone is entitled to
make decisions provided that they follow the rules defined by the active
maintainers. And rules can be changed through discussion between active
contributors when reaching a consensus...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Replace the TC power to depose maintainers

[Andreas Tille]

On Fri, Dec 02, 2016 at 01:39:30PM +, Holger Levsen wrote:
> On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > > 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.
> > Why would this be taken away?
>  
> motivation works in strange ways. and it doesnt work the same all of us
> too…

I agree that motivation is important and different.  From my personal
point of view it does not matter who is named in the Maintainer field
but in the latest changelog field since this person has done recent
work.  To support this I frequently leave "Team uploads" of people who
did a slight contribution in a changelog with several people
contributing instead of simply using my Uploader hat to become changelog
owner.  So we have several packages uploaded by GSoC students who
contributed autopkgtests and these changelog owners are even prominently
displayed on the Debian Med tasks pages.
 
> I do agree with zack's original goal here however. And I also understood that
> he is well aware that this needs changes in our culture. I just wanted to
> point out that this aspect of our  cultur is not only harmful but also has
> huge benefits. 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.

I admit I do not mind about the name of the field as long as the
principle which Zack had in mind will be realised.  BTW, keeping the
Maintainer field as a mailing list address - and allow only mailing
lists there is another option.

Kind regards

  Andreas.

[1] Feel free to seek for "Canberk Koç" and "Tatiana Malygina" at
https://blends.debian.org/med/tasks/bio

-- 
http://fam-tille.de

Re: Replace the TC power to depose maintainers

[Andreas Tille]

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

Re: Replace the TC power to depose maintainers

[Piotr Ożarowski]

[Scott Kitterman, 2016-12-08]
> I feel a personal sense of responsibility towards the packages where I appear 
> as Maintainer or in Uploaders.  In my mind, adding myself there represents 
> both authority to make decisions and responsibilities.  
> 
> Take that away and I do believe I'll feel less responsible and less motivated.
> 
> For packages maintained by myself or in ~small teams, things like work flow 
> and tools are tractable in a way they aren't for the project as a whole.
> 
> While our current system has disadvantages, I have yet to see a better 
> alternative proposed.

+1

(/me will orphan all of his packages if Debian decides they're not his
anymore)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Replace the TC power to depose maintainers

[Scott Kitterman]

On Wednesday, December 07, 2016 11:21:23 AM Stefano Zacchiroli wrote:
> On Tue, Dec 06, 2016 at 02:29:13PM +, Ian Jackson wrote:
> > Can we come up with some way whereby the maintainership authority is
> > always shared, somehow ?
> 
> The net result of this would be that anyone who maintains packages in
> Debian will do so as part of a team. Likely, people maintaining more
> than one package will end up being part of several teams.
> 
> In such a hypothetical world you seem to be persuaded that, within all
> those teams, people will generally learn to work together amicably and
> find ways to avoid stepping on each other toes. This definitely matches
> my teamwork experience in Debian --- Sometimes you, as a team member,
> are confident you're doing the right thing, and will just go ahead and
> make a change. Sometimes you'll have doubts and ask before acting.
> Sometimes you'll screw things up, and either you'll clean up after
> yourself or someone else will do so for you (when this happens, cursing
> will be involved).
> 
> So my question here is: why would someone who has learned to work
> amicably *within* the boundaries of several teams, will behave any
> different *across* those boundaries, when contributing to packages that
> belong to other teams? I think the behavior will be the same. So, if we
> go down this path, I'm not sure why we should stop at teams, instead of
> just having the de facto equivalent of "Maintainer: Debian" for all
> packages.
> 
> *Of course* there will be conflicts, but it is absolutely not clear to
> me why they would be any worse, or any more frequent, than the conflicts
> we have today within (potentially very large) teams.
> 
> [ As a caveat: the "Maintainer" field currently acts as both a contact
>   point for a given package, and as "fences" separating who is allowed
>   to contribute without asking for permission and who should ask first.
>   I'm advocating only against the latter meaning, not the former. But
>   the former can be implemented in other ways. For instance, Nicolas
>   Dandrimont pointed me to the fact that Fedora uses as contact point a
>   list of the most recent N committers to any given package. Which
>   sounds like a great solution. ]

I feel a personal sense of responsibility towards the packages where I appear 
as Maintainer or in Uploaders.  In my mind, adding myself there represents 
both authority to make decisions and responsibilities.  

Take that away and I do believe I'll feel less responsible and less motivated.

For packages maintained by myself or in ~small teams, things like work flow 
and tools are tractable in a way they aren't for the project as a whole.

While our current system has disadvantages, I have yet to see a better 
alternative proposed.

Scott K

signature.asc
Description: This is a digitally signed message part.

Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers)

[Guillem Jover]

On Thu, 2016-12-01 at 19:20:36 +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
> 
> This is the obviously right solution.

It is not only not obviously right to me, instead it seems obvious
it carries a set of different problems with it. I feel this carries
so many assumptions of how the proposers feel about how *they* work
or might like to work and ignores how *others* do that. :/

If Debian was operated by a hive-mind, this would be the obvious
solution. But Debian is not (and it should not become a hive-mind IMO),
instead its distributed, independent and diverse nature is one of its
greatest strengths. In addition Debian is in great part a volunteer
based project. The dynamics on a volunteer vs a paid environment can
be entirely different (they are for me, there are things I'm willing
to do or scenarios I'm willing to accept/tolerate on paid-basis, I'd
never do on a volunteer one).

Few problems that come to mind on a fully maintainerless project:

* Encourages one-off upload-and-forget for dependencies of stuff one
  might want to package.
* More difficult to track (in and outside of Debian) if there is
  supposedly someone taking care of those package (would require
  accessing subscribers from the PTS or tracker or similar?). Is
  someone supposedly taking care of orphaned packages? Well perhaps,
  no one know until there's an upload. Is someone maintaining a
  maintained packages, in the normal case, yes.
* No one will have a "vision" of where each of those packages is or
  should go? Will this vision need to be agreed by the whole project?
  For each package!?
* Assumes stable and interpersonal relationships with upstreams are
  perhaps not important? Everytime someone different might contact
  upstream with a different style, etc?
* Assumes that everyone enjoys working with the same tools, with the
  same workflows: what about cdbs vs dh vs dehelper, git vs the rest,
  VCS layouts (debian-only, full-upstream, pristine-tar), source format
  1.0 vs 3.0, etc, etc. (f.ex. there are several VCSs, source layouts,
  helpers, etc. I'm so uncomfortable working with, to the point I just
  don't feel like co-maintaining packages using those, or join teams
  that have those as their team policy).
* Assumes everyone is pulling Debian in the same direction, and that
  there are never potentially opposite goals (at least initially).
* Assumes everyone can work with everyone else on a close and personal
  level (f.ex. I'll accept technical contributions from anyone based
  on the merits of those contributions, but there are people I'd rather
  not have to work with closely).
* Assumes an extrovert worldview. Sole-maintainership is not necessarily
  about control, authority and power (inbalanace!?) it can also be a
  sanctuary of tranquility, having to coordinate with a team or the whole
  project can imply an additional overhead and energy toll for introverts,
  in addition to the required coordination and interactions we are
  supposed to carry on as normal duty towards others and the project.
  Or it can be a space of freedom where one can do (within the
  distro-wide technical and socual rules and policies) anything one
  can imagine.
* Assumes everyone has the same personal packaging policies and
  commitment of effort. For example whether to strive for 0-divergence
  against upstream, or whether to patch upstream with no remorse
  whenever it seems needed. (I'm on the latter camp, but I'd never
  impose that vision on people on the first camp, because that would
  imply I'm deciding on a work committment for them).
* Assumes everyone perceives and feels their time and effort involvement
  on tasks in the same way. While the motivations and rewards are so
  subtle and diverse, probably as the number of people we have involved.
* With less and less people checking central development communication
  channels, many global distribution-wide changes have no way to be
  considered by the majority of affected people. While being able to
  do distro-wide changes, in say, a mass upload, might be very
  convenient, having independent maintainers that *know* the details
  of the packages they maintain means there are more sanity checks in
  place, and that you need to convince people your ideas are correct.
* Could discourage experimentation, using new tools, helpers, techniques,
  workflows, because it might interfere with others wanting to work
  also on those packages (it would go against the hive-mind!).

I've worked on teams or group efforts that are great, with great peers
that I resonate with on an interpersonal level, where I might or might
not agree on the technical level, but technical discussions are still
very much enjoyable. I've also worked on teams that were such an
energy drain that they were very unpleasant to work in.

I think all of sole-maintainership, team maintainership, and even
maintainerless packages have 

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose maintainers"):
> If one feels the source package isn't kept up-to-date enough, she
> can "just" file an ITP for a new source package name, pointing to
> hir attempts at convincing the existing maintainers. As ITPs are
> CC'ed to -devel, it becomes a matter of cultural shift in how we
> (and FTP Master, Release Team, etc) accept parallel versions in the
> archive (same software in different source & binary package names).

I like this idea.  Thinking "aloud":

There is problem with security support burden.  Perhaps the security
team could desupport all but one "version" - but then isn't the
security team in the business of judging somehow ?  I'm not sure if
they want to do that.

This wouldn't work for all packages, and it wouldn't work for
situations where (for example) the maintainers of a large subsystem
decided to make a controversial change across many packages.

But it would be a useful tool to have in our toolbox.

Ian.

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

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> So my question here is: why would someone who has learned to work
> amicably *within* the boundaries of several teams, will behave any
> different *across* those boundaries, when contributing to packages that
> belong to other teams? I think the behavior will be the same. So, if we
> go down this path, I'm not sure why we should stop at teams, instead of
> just having the de facto equivalent of "Maintainer: Debian" for all
> packages.

There is a big difference between a small(ish) team where you can
build and then rely on personal relationships, and the whole of
Debian, where that is much more difficult.

Also there are practical problems.  Different people have different
ideas about source code layout, preferred build system, vcs workflow,
and so on.  These questions don't have unambiguously right answers and
are largely matters of taste.  On the other hand they are very much in
your face when doing practical work.  Without the benefit of a clear
authority who can make these decisions, we would risk spending too
much time debating them.  (I think that we have too much difference in
workflows etc., but I don't think we want to try to force everyone
into a single way of doing things.)

Ian.

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

Re: Replace the TC power to depose maintainers

[Stefano Zacchiroli]

On Tue, Dec 06, 2016 at 02:29:13PM +, Ian Jackson wrote:
> Can we come up with some way whereby the maintainership authority is
> always shared, somehow ?

The net result of this would be that anyone who maintains packages in
Debian will do so as part of a team. Likely, people maintaining more
than one package will end up being part of several teams.

In such a hypothetical world you seem to be persuaded that, within all
those teams, people will generally learn to work together amicably and
find ways to avoid stepping on each other toes. This definitely matches
my teamwork experience in Debian --- Sometimes you, as a team member,
are confident you're doing the right thing, and will just go ahead and
make a change. Sometimes you'll have doubts and ask before acting.
Sometimes you'll screw things up, and either you'll clean up after
yourself or someone else will do so for you (when this happens, cursing
will be involved).

So my question here is: why would someone who has learned to work
amicably *within* the boundaries of several teams, will behave any
different *across* those boundaries, when contributing to packages that
belong to other teams? I think the behavior will be the same. So, if we
go down this path, I'm not sure why we should stop at teams, instead of
just having the de facto equivalent of "Maintainer: Debian" for all
packages.

*Of course* there will be conflicts, but it is absolutely not clear to
me why they would be any worse, or any more frequent, than the conflicts
we have today within (potentially very large) teams.

[ As a caveat: the "Maintainer" field currently acts as both a contact
  point for a given package, and as "fences" separating who is allowed
  to contribute without asking for permission and who should ask first.
  I'm advocating only against the latter meaning, not the former. But
  the former can be implemented in other ways. For instance, Nicolas
  Dandrimont pointed me to the fact that Fedora uses as contact point a
  list of the most recent N committers to any given package. Which
  sounds like a great solution. ]

Cheers.
-- 
Stefano Zacchiroli . z...@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 »


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Didier 'OdyX' Raboud]

Le mercredi, 7 décembre 2016, 08.49:57 h CET Russell Stuart a écrit :
> Why not have a formal rule that says if a package in Debian is out of
> date for more than one release cycle any DD can package it under a
> different name, after going through the usual ITP procedures coupled
> with a bug report to the original package citing the ITP and a delay?
> It's not like we don't do the parallel versions bit now - squid /
> squid3, exim / exim4 and so on.

Or just the same, but without too many formalities:

If one feels the source package isn't kept up-to-date enough, she can "just" 
file an ITP for a new source package name, pointing to hir attempts at 
convincing the existing maintainers. As ITPs are CC'ed to -devel, it becomes a 
matter of cultural shift in how we (and FTP Master, Release Team, etc) accept 
parallel versions in the archive (same software in different source & binary 
package names).

With snapshots.debian.org and LTS in place, we could also start accepting that 
there is a variety of cases where it's entirely fine to instruct users to 
install versions from past stable versions. (lsb-desktop in Wheezy had such 
instructions, if one needed to get Qt3, e.g.)

-- 
Cheers,
OdyX

Re: Replace the TC power to depose maintainers

[Russell Stuart]

On Thu, 2016-12-01 at 15:46 +, 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;
>  * 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.

The points are technical decisions someone has to adjudicate on,
however if occurred to me this one could be handled differently:

> * The package is years out of date compared to upstream, afflicted by
>bitrot, and many users are asking for the new version;

Why not have a formal rule that says if a package in Debian is out of
date for more than one release cycle any DD can package it under a
different name, after going through the usual ITP procedures coupled
with a bug report to the original package citing the ITP and a delay? 
It's not like we don't do the parallel versions bit now - squid /
squid3, exim / exim4 and so on.

The original packager isn't powerless when this happens as he can stop
the procedure in it's tracks by simply upgrading his package within the
delay period.

We already have done something like this with live-build-ng / live-
wrapper.  It wasn't a pleasant process but it did produce a decision
that allowed everyone to move on.  That included Daniel.  He chose to
stop maintaining live-build, but he also could have continued with his
package and let popcon decide, or he could have taken another look at
whatever features the CD group wanted.

signature.asc
Description: This is a digitally signed message part

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead,

I was thinking about what Scott wrote, and also went back and read
some of the bug log he is referring to.  I wonder if there is an
underlying a useful observation about the merits of team maintenance.

Most of the really bad cases I have seen have been a single
maintainer.  In packages with more than one person involved, even if
there is someone in the team whose communication skils are not
brilliant, it is normally possible to work with the rest of the team.

There is of course a possibility that a whole team might get a kind of
groupthink.  I have indeed seen that in a few situations, but it is
obviously very rarely practical to replace a whole team, even if a
decision to do so could somehow be made.


Can we come up with some way whereby the maintainership authority is
always shared, somehow ?  Either with a team, or with the whole
project (QA-style), or with the first person who comes along and wants
to try to help ?

Is there a way to do this that would work in practice ?

Some ideas:

 * Document that all packages ought to have several maintainers, if
   there are people available to do that job.

 * A new rule that for a package where only one human being is named
   in Maintainer/Uploaders, any DD who wants to help the package
   SHOULD add themselves to Uploaders and thereby become a maintainer
   equal in standing to the existing maintainer.

   That is, discourage NMUing a sole-maintained package, in favour of
   joining its as a maintainer - importantly, to encourage joining as
   a maintainer without asking first.

   So the process would be:

   Alice sees that a package is solo-maintaineed, and there is
   something she wants to fix in it.  She uploads to NMU/DELAYED-7
   adding herself to Maintainers, and maybe fixing any easy RC bugs.
   She also simultaneously emails the maintainer to introduce herself,
   offer her help, and consult on plans for the future of the package.

   Something like:

  Hi, Bob.  I was looking at gnomovision, and saw that you seem to
  be dealing with it alone.  I would like to help so I have taken
  the liberty of becoming a maintainer, with my upload which I
  have just pushed to DELAYED-7.

  I also fixed #890123 (the RC bug) in what I hope is the right
  way.  Please let me know if I got it wrong.

  To be honest, I don't have a great deal of time for doing major
  work on gnomovision but I can help deal with obvious problems
  and help keep the package in tolerable shape.  As you will know,
  we (Debian) recently decided that it's better for me to formally
  become a maintainer of a package which would otherwise have only
  one person looking after it.

  I hope this all seems good to you and I look forward to working
  with you.

  Regards,
  Alice.

 * Change the dev ref so that if a package has only one maintainer,
   any upload should be considered a maintainer upload and the usual
   NMU rules do not need to be followed ?

   Probably bad because no-one will want to do such a hostile act.

 * Explicit authority for the MIA team to declare that someone is no
   longer a maintainer, to avoid Maintainer fields giving the
   appearance of multiple maintainers when actually there is only one
   maintainer right now.

 * Disputes within maintainership teams might have to end up in front
   of the TC, more often.  But then the question is much more "what is
   the best way to do X or Y".

 * Maintainership to be recorded elsewhere so that it is not
   neccessary to upload to change the maintainer.

   There could be a web UI in which SSO-logged-in DDs could see a
   "join team for this package" button which would automatically join
   the team if there was a sole maintainer, but would turn into an
   "apply to join the team" button if there were at least three
   existing maintainers.

Or something.

Ian.

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

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"):
> 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.  [etc.]

Thanks for sharing your experience.  I know that's something that
sounds like a formula that people say, but I really really mean it.

> I don't expect you to agree,

I don't feel I can disagree with your report of your experience.  And,
going back and looking at the report for the bug, I can see why you
feel the way you do.  Some of your messages in that bug log make quite
cogent arguments.

I haven't changed my mind that the problem of difficult maintainers
desperately needs a solution.  And I haven't really changed my mind
about what the TC should do in the current case.

But I feel you have significantly shifted my view about what should be
done about the general problem; or, alternatively, about how these
things should be dealt with in the future.

I'm more towards the view now that the TC framework/process simply
cannot deal with these problems in a just way.

I am going to write a separate mail in a different bit of the
subthread, with some different ideas you have prompted me to think of.

Regards,
Ian.

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

Re: Replace the TC power to depose maintainers

[Tollef Fog Heen]

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

[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

[Scott Kitterman]

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

[Ian Jackson]

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

Re: Replace the TC power to depose maintainers

[Scott Kitterman]

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

[Matthew Woodcraft]

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]

[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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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

Re: Replace the TC power to depose maintainers

[Philip Hands]

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

[Tollef Fog Heen]

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

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

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

[Tollef Fog Heen]

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

[Tollef Fog Heen]

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

[Tollef Fog Heen]

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

[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

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> 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

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> 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]

[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 <ijack...@chiark.greenend.org.uk> 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 <ijack...@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.

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

[Russ Allbery]

Ian Jackson <ijack...@chiark.greenend.org.uk> 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)   <http://www.eyrie.org/~eagle/>

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:

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

Re: Replace the TC power to depose maintainers

[Didier 'OdyX' Raboud]

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]

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

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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

Re: Replace the TC power to depose maintainers

[Didier 'OdyX' Raboud]

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

[Didier 'OdyX' Raboud]

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]

[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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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.

Re: Replace the TC power to depose maintainers

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Holger Levsen writes ("Re: Replace the TC power to depose maintainers"):
>> On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
>> >  DRAFT GENERAL RESOLUTION STARTS
>> > 
>> >  OPTION A
>>  
>> = "keep the status quo"
>
> AIUI, no.
>
> Empirically, practice by the TC is to almost always uphold the
> maintainer, and never to depose them.
>
> At least one TC member has told me that if this GR text passed, they
> would resign from the TC, because it would amount to a declaration of
> lack of confidence in the TC.

For the avoidance of doubt, that was me, here:

  https://lists.debian.org/debian-ctte/2016/12/msg00012.html

The point being that if the project decided not only to go to the effort
of having a vote, but to actually vote in favour of this NOOP, it would
very strongly imply that the TC had lost the trust of the project.  (You
don't send a duplicate copy of someone's contract of employment, with
some added micro-management clauses, to someone that's doing a good job).

We cannot perform our function without the project's trust, so of course
I'd resign if that happened -- not that I consider that likely, but then
again this is 2016 ... anything might happen. ;-)

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

[Jérémy Bobbio]

Mattia Rizzolo:
> On Thu, Dec 01, 2016 at 03:46:05PM +, 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.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Holger Levsen writes ("Re: Replace the TC power to depose maintainers"):
> On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
> >  DRAFT GENERAL RESOLUTION STARTS
> > 
> >  OPTION A
>  
> = "keep the status quo"

AIUI, no.

Empirically, practice by the TC is to almost always uphold the
maintainer, and never to depose them.

At least one TC member has told me that if this GR text passed, they
would resign from the TC, because it would amount to a declaration of
lack of confidence in the TC.

Well, it is true that I have lack of confidence in the TC.  But I
don't want the TC members to resign and be replaced.  My lack of
confidence is in the TC as an institution; as a framework; or as a
cultural/political practice.  I don't have a problem with the
individuals.

Ian.

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

Re: Replace the TC power to depose maintainers

[David Bremner]

Sheetal Shalini  writes:

> Hi
>
> How do I unsubscribe from Debian Project mailing list?
>

see the instructions on

https://lists.debian.org/debian-project/

Re: Replace the TC power to depose maintainers

[Holger Levsen]

On Fri, Dec 02, 2016 at 03:42:58PM +, Ian Jackson wrote:
>  DRAFT GENERAL RESOLUTION STARTS
> 
>  OPTION A
 
= "keep the status quo"

>  OPTION B

equals:
 
>  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".
 

is this a correct summary of this draft?

If so, I'd be intersted in current TC members position on this.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Replace the TC power to depose maintainers

[Sheetal Shalini]

Hi

How do I unsubscribe from Debian Project mailing list?




Thanks and Regards.

Sheetal Shalini
3rd Year B.Tech CSE
NITK Surathkal


On Sat, Dec 3, 2016 at 4:12 PM, Paul Wise  wrote:

> 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?
>
> > I was there at the time; this may even have been my fault.  Sorry.
>
> No worries, this is all hindsight talking.
>
> > That was madness.  We should have just fixed the things that wanted a
> > single email address for that field.
> >
> > We could still do this.  "Team maintained" packages would end up with
> >   Maintainer: Alice, Bob, Cryptographic Tales Team
>
> Instead, I'd kill Maintainer and use DEP-2 to manage who gets email for
> a package, especially since that changes independently of packages.
>
> > Oh god please no.  I wouldn't ever want to make any such statement.
>
> Technically, you already are, with Maintainer/Uploaders :)
>
> https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: Replace the TC power to depose maintainers

[Paul Wise]

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?

> I was there at the time; this may even have been my fault.  Sorry.

No worries, this is all hindsight talking.

> That was madness.  We should have just fixed the things that wanted a
> single email address for that field.
> 
> We could still do this.  "Team maintained" packages would end up with
>   Maintainer: Alice, Bob, Cryptographic Tales Team

Instead, I'd kill Maintainer and use DEP-2 to manage who gets email for
a package, especially since that changes independently of packages.

> Oh god please no.  I wouldn't ever want to make any such statement.

Technically, you already are, with Maintainer/Uploaders :)

https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Replace the TC power to depose maintainers

[Sheetal Shalini]

Hi

How do I unsubscribe from the debian project mailing list?

On Dec 1, 2016 9:48 PM, "Mattia Rizzolo"  wrote:

> On Thu, Dec 01, 2016 at 03:46:05PM +, 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 

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Paul Wise writes ("Re: Replace the TC power to depose maintainers"):
> I'd like to reframe this discussion a little bit...
> 
> What exactly is the Maintainer* field for?
> 
> Initially it was a way for individuals to declare their commitment to
> perform all tasks in relation to a package.

Not at all.

Mainly, it was a way to control who got email about the package.

> * and why did we make the huge mistake of not calling it Maintainers

I was there at the time; this may even have been my fault.  Sorry.

> and then making the secondary mistake of introducing Uploaders instead
> of renaming it to Maintainers.

That was madness.  We should have just fixed the things that wanted a
single email address for that field.

We could still do this.  "Team maintained" packages would end up with
  Maintainer: Alice, Bob, Cryptographic Tales Team

> I would like to see Maintainer/Uploaders replaced with some sort of
> fine-grained commitment registration system:
> 
> I commit to [stuff]

Oh god please no.  I wouldn't ever want to make any such statement.

Ian.

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

Re: Replace the TC power to depose maintainers

[Paul Wise]

On Sat, Dec 3, 2016 at 6:20 AM, Raphael Hertzog wrote:

> We could get rid of "Maintainer" in debian/control and still display
> on tracker.debian.org the name of people who are uploading/committing
> in a dynamic "Maintainer" section.
>
> Actually, this is part of my grand-plan... :-) aka
> http://dep.debian.net/deps/dep2/

I'd like to reframe this discussion a little bit...

What exactly is the Maintainer* field for?

Initially it was a way for individuals to declare their commitment to
perform all tasks in relation to a package.

Today, as well as being conflated with package ownership, I feel that
it does not sufficiently represent the reality of individual
commitments towards actions needed for packages, for
Maintainers/Uploaders, the Debian packaging community in general and
other people.

I would like to see Maintainer/Uploaders replaced with some sort of
fine-grained commitment registration system:

I commit to spending 3 hours per week on $package.
I commit to triaging bugs on $package.
I commit to working on RC bugs on $package.
I commit to testing proposed security updates on $package.
I commit to testing alpha versions of $package.
I commit to reviewing changes to $package.
I commit to sponsoring non-member updates to $package.

* and why did we make the huge mistake of not calling it Maintainers
and then making the secondary mistake of introducing Uploaders instead
of renaming it to Maintainers.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Replace the TC power to depose maintainers

[Raphael Hertzog]

On Fri, 02 Dec 2016, Holger Levsen wrote:
> I'm not saying people like you dont exist, nor that your reasoning aint
> sensible. I've just said some people take motivation from being listed
> as maintainer.

We could get rid of "Maintainer" in debian/control and still display
on tracker.debian.org the name of people who are uploading/committing
in a dynamic "Maintainer" section.

Actually, this is part of my grand-plan... :-) aka
http://dep.debian.net/deps/dep2/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Replace the TC power to depose maintainers

[Iustin Pop]

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


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > 3. Abolish maintainership entirely.
> 
> This is the obviously right solution.

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

 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.

 3. We give advice to the Technical Committee:

 4. The Technical Committee should consider all opinions and options
based on their merits, not based on the authority of the speaker.

The opinions of the current maintainer are as relevant as the
opinions of other contributors, users, and other stakeholders.
But they are no more relevant.

 5. Specifically, when making any decision with respect to a package,
the TC should not pay attention to the formal maintainership
status of the package.

On the other hand, it is relevant to give more weight to a
contributor who has a strong record of contributions to the
package; shows depth and accuracy of knowledge about it; or has
shown consistently good communication, stewardship and leadership.

 6. Our advice specifically includes decisions on who the maintainer
should be, under Constitution 6.1(2), or whether to overrule the
maintainer, under 6.1(4).

 7. The constitutional 3:1 majority is a sufficient safeguard against
undue interference with the work of individual maintainers.

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

Ian.

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

Re: Replace the TC power to depose maintainers

[Mattia Rizzolo]

On Fri, Dec 02, 2016 at 01:39:30PM +, Holger Levsen wrote:
> On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > > 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.
> > Why would this be taken away?
>  
> motivation works in strange ways. and it doesnt work the same all of us
> too…

Example (that I feel is about to happen to me too): a package where
you're listed as Maintainer, you used to be interested in it, now you
are not anymore; you should probably orphan or RFA it, but you still
care a bit about it and you're keeping it very well because you're a
great maintainer nonetheless.  I think that if I were forced to remove
my name from it I'd just forget and let it go to waste by discarding
that bit that I cared about.

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


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Adam Borowski]

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?

Re: Replace the TC power to depose maintainers

[Holger Levsen]

On Fri, Dec 02, 2016 at 01:40:31PM +0100, Johannes Schauer wrote:
> > 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.
> Why would this be taken away?
 
motivation works in strange ways. and it doesnt work the same all of us
too…

> If the majority of recent debian/changelog entries are by you, I would claim
> that it's no problem for you to still call yourself the maintainer because
> apparently that's what you are doing: maintaining a package. It's just that
> others could potentially also upload fixes. But it doesn't take away the work
> you do or that you are doing most of it. That you are doing most of it will
> still be visible.

while true, your "story" doesnt take into account those who "need" to be
listed in the maintainer field to feel proud, responsible, etc.

I'm not saying people like you dont exist, nor that your reasoning aint
sensible. I've just said some people take motivation from being listed
as maintainer.

I'll add that motivation onced harmed is hard to bring back.

> Counter example to your argument:
[...] 
> I agree, it feels great to be called the maintainer of $foo, but in my
> experience people call you "the maintainer" even if you haven't maintained 
> that
> thing for a very long time, the package is team maintained and you are not 
> even
> in the Uploaders field.

Your counter example doesnt invalidate my example at all. It's great
that we will keep you as the sbuild maintainer, just imagine how stupid
it would be to loose others because this is important to them.

Even unconsciously important.


I do agree with zack's original goal here however. And I also understood that
he is well aware that this needs changes in our culture. I just wanted to
point out that this aspect of our  cultur is not only harmful but also has
huge benefits. 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.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Johannes Schauer]

Hi,

Quoting Holger Levsen (2016-12-02 13:11:05)
> 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 +, 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.

Why would this be taken away?

If the majority of recent debian/changelog entries are by you, I would claim
that it's no problem for you to still call yourself the maintainer because
apparently that's what you are doing: maintaining a package. It's just that
others could potentially also upload fixes. But it doesn't take away the work
you do or that you are doing most of it. That you are doing most of it will
still be visible.

Counter example to your argument:

People have repeatedly called me "the sbuild maintainer" and that is despite:

 - my first sbuild upload was only a little more than a year ago
 - the package is still team maintained
 - I only added myself to the Uploaders field four weeks ago

I agree, it feels great to be called the maintainer of $foo, but in my
experience people call you "the maintainer" even if you haven't maintained that
thing for a very long time, the package is team maintained and you are not even
in the Uploaders field.

cheers, josch


signature.asc
Description: signature

Re: Replace the TC power to depose maintainers

[Johannes Schauer]

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 +, 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.  S

Re: Replace the TC power to depose maintainers

[Holger Levsen]

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 +, 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


signature.asc
Description: Digital signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> On Thu, Dec 01, 2016 at 03:46:05PM +, 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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Mattia Rizzolo]

On Thu, Dec 01, 2016 at 06:26:28PM +, 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  `-


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Clint Adams]

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.

Re: Replace the TC power to depose maintainers

[Stefano Zacchiroli]

On Thu, Dec 01, 2016 at 03:46:05PM +, 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 . z...@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 »


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Mattia Rizzolo]

On Thu, Dec 01, 2016 at 06:00:42PM +, 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  `-


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Vincent Bernat]

 ❦  1 décembre 2016 15:46 GMT, Ian Jackson  :

> 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


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Ian Jackson]

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 <ijack...@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.

Re: Replace the TC power to depose maintainers

[Sean Whitton]

Hello,

On Thu, Dec 01, 2016 at 03:46:05PM +, 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


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Mattia Rizzolo]

On Thu, Dec 01, 2016 at 03:46:05PM +, 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,