Re: Replace the TC power to depose maintainers
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
]] 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
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
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
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
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
Ian Jacksonwrites: > 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
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)
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
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
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
[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
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)
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
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
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
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
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
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
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
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
]] Ian Jackson There's no need to Cc me on replies, I'm subscribed already. > Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"): > > Because I generally find it's generally the wrong tool for the job. If > > I can come up with a good explanation for why somebody should take a > > particular course of action (which I need before I'm willing to override > > anybody), and I take the time to explain it to them and discuss with > > them, I find we usually end up agreeing. > > That is of course mostly true of disagreements. > > But it is not mostly true of problems which come to the TC. > > Of course sometimes the TC will find that getting people to explain > themselves clearly will cause the dispute to evaporate. I remember > that happening about twice during my term. But it's easy to tell > when this happens because both parties go away happy and say they > don't need the TC's help any more. That's not my experience. They'll go away grumbling because they both had to make some sort of concession(s). The goal of the current dispute isn't to get global a new maintainer. It's to ensure the package is of as good quality in Stretch and beyond. This is balanced by the goal of not making too many people too sad or annoyed, not taking on lots of technical debt or crazy design decision and so on. > > The goal is not to end up with a new maintainer. Deposing a maintainer > > or overriding them is sometimes a necessary evil, but it's never my > > first option. > > Surely the goal should be to make Debian as good a social and > technical space as possible. I didn't say what the goal was, I pointed out what it was not. > If the maintainer is exercising poor leadership - poor enough that > someone has risked coming to the TC with it - then that goal is best > served by replacing them. Based on that argument, the TC should just rubberstamp all appeals and always grant them, which is surely not what you mean. Also what ScottK writes about being «on trial» (which is what it feels like) as quite uncomfortable for the maintainer. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Ian Jackson > Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and > 1 more messages]"): > Lars Wirzenius > > > I suggest a lighter approach than a GR for eroding the strong package > > > ownership further is to start another page, "LowThresholdHijack" or > > > something, listing maintainers who are OK if someone hijacks their > > > package if the maintainer isn't taking good care of it. Would anyone > > > else than I put themselves on that new page? (If you would, start the > > > page on the wiki and announce it on this thread, and I'll add myself.) > > > > A similar proposal: Have a way of declaring the package to be under > > collective maintenance (put it under collab-maint on alioth + > > Maintainer: collect...@debian.org or somesuch?) That'd move closer to a > > model where individuals don't own that particular package. > > This is all very well and good, but frankly, Lars (and the others in > this conversation) are not the problem. The problem maintainers won't > put themselves on a LowThresholdAdoption list either. > > We already have ways of dealing with maintainers who are simply > absent or busy, and not actively resisting. Our processes for that > are rather cumbersome but it is possible to use them effectively. > > What we lack is a way of dealing with maintainers who are determined > not to lose control of their packages. (And I do mean "control".) I believe that cultural change can happen through collective action on an individual level, rather than sweeping regulation and legislation. The culture around NMUs has changed _immensely_ in the years I've been involved in the project. Nowadays, they're a pretty routine matter (as an example, look at the conflict over global where the petitioners have NMUed a newer version into experimental where this isn't really that big a deal). I believe our view of maintainership can change similarly if enough people say «here are the keys to the kingd^Wpackage, please be considerate», even for the packages which are not collectivised. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
On Monday, December 05, 2016 11:18:41 PM Ian Jackson wrote: > Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"): > > Nonsense. There's no risk for a non-maintainer to come to the TC. > > A non-maintainer who comes to the TC: > > * Is very likely to find that already unpleasant situation, gets >emotionally worse, at least temporarily; > > * Is probably interested in the package in question, and so risks >their future contributions being devalued or ignored; > > * Is probably an advanced user of the package and may be dependent on >the package (to some degree or other) continuing to support their >use cases rather than the maintainer letting them rot or even >sabotaging them; > > * Is likely to worry that they will gain enemies. > > These are distinctly nontrivial risks. Most of the risks are social > in some sense. Some of them are practical. They will put off most > petitioners, given that the likelihood of the TC escalation being > useful to them is very small. Having been involved in one of these things even as a maintainer of a package that was not directly the target of the request to the TC was extremely trying. It was by a large margin the second most unpleasant and stressful free software experience I've had even though the TC, in the end, supported the existing maintainers. If it came up again, I'd probably just orphan the package immediately rather than deal with the process again. That's how awful it is from the side you claim is all empowered. The non-maintainer risks are trivial in comparison to the maintainer who risks having their volunteer work for Debian thrown away and the virtual certainty that they were not going to be able to contribute any more to a package they thought was important enough to put time and effort into. I don't expect you to agree, but if anything, I see all the advantage with the non-maintainers. I'm glad the TC has my back (and I'm sure if I screw something up badly enough, they'll help me see it). Scott K
Re: Replace the TC power to depose maintainers
Scott Kitterman writes ("Re: Replace the TC power to depose maintainers"): > Nonsense. There's no risk for a non-maintainer to come to the TC. A non-maintainer who comes to the TC: * Is very likely to find that already unpleasant situation, gets emotionally worse, at least temporarily; * Is probably interested in the package in question, and so risks their future contributions being devalued or ignored; * Is probably an advanced user of the package and may be dependent on the package (to some degree or other) continuing to support their use cases rather than the maintainer letting them rot or even sabotaging them; * Is likely to worry that they will gain enemies. These are distinctly nontrivial risks. Most of the risks are social in some sense. Some of them are practical. They will put off most petitioners, given that the likelihood of the TC escalation being useful to them is very small. Ian. -- Ian 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
On Monday, December 05, 2016 10:02:02 PM Ian Jackson wrote: > Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"): > > Because I generally find it's generally the wrong tool for the job. If > > I can come up with a good explanation for why somebody should take a > > particular course of action (which I need before I'm willing to override > > anybody), and I take the time to explain it to them and discuss with > > them, I find we usually end up agreeing. > > That is of course mostly true of disagreements. > > But it is not mostly true of problems which come to the TC. > > Of course sometimes the TC will find that getting people to explain > themselves clearly will cause the dispute to evaporate. I remember > that happening about twice during my term. But it's easy to tell > when this happens because both parties go away happy and say they > don't need the TC's help any more. > > > The goal is not to end up with a new maintainer. Deposing a maintainer > > or overriding them is sometimes a necessary evil, but it's never my > > first option. > > Surely the goal should be to make Debian as good a social and > technical space as possible. > > If the maintainer is exercising poor leadership - poor enough that > someone has risked coming to the TC with it - then that goal is best > served by replacing them. Nonsense. There's no risk for a non-maintainer to come to the TC. Worst case scenario for the non-maintainer is the status quo. The maintainer, on the other hand, has everything to lose and nothing to gain. The one time I was peripherally involved in one of these it was long, painful, and no one got what they wanted, but some things did change and Debian is the better for the changes (I think they would have happened without the TC escalation, but that's a counter factual that can't be proven). In my admittedly limited experience, the worst possible thing the TC could have done was make a rapid decision. Scott K
Re: Replace the TC power to depose maintainers
On 2016-12-05 20:57, Philip Hands wrote: > Tollef Fog Heenwrites: >> ]] Ian Jackson >>> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >>> weeks during which members of the TC have been prevaricating. >> What are you accusing the TC of lying about? > I think that British English has drifted into using that as a synonym > for procrastinate while American English seems to have stuck to its > earlier meaning (judging by the online dictionary entries I see). There has evidently been drift in both languages. The current full Oxford English Dictionary lists only two senses (when used as an intransitive verb) as non-obsolete: a. To deviate from straightforwardness; to speak or act in an evasive way; to quibble, equivocate. (with citations back to 1623) b. To behave evasively or indecisively so as to delay action; to procrastinate. (with citations back to 1854) It says that the second is "now the usual sense". I can find some American dictionaries which strengthen sense 'a' to include "deliberately mislead" or even "lie", but that is not standard British usage. -M-
Re: Replace the TC power to depose maintainers [and 1 more messages]
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and 1 more messages]"): Lars Wirzenius > > I suggest a lighter approach than a GR for eroding the strong package > > ownership further is to start another page, "LowThresholdHijack" or > > something, listing maintainers who are OK if someone hijacks their > > package if the maintainer isn't taking good care of it. Would anyone > > else than I put themselves on that new page? (If you would, start the > > page on the wiki and announce it on this thread, and I'll add myself.) > > A similar proposal: Have a way of declaring the package to be under > collective maintenance (put it under collab-maint on alioth + > Maintainer: collect...@debian.org or somesuch?) That'd move closer to a > model where individuals don't own that particular package. This is all very well and good, but frankly, Lars (and the others in this conversation) are not the problem. The problem maintainers won't put themselves on a LowThresholdAdoption list either. We already have ways of dealing with maintainers who are simply absent or busy, and not actively resisting. Our processes for that are rather cumbersome but it is possible to use them effectively. What we lack is a way of dealing with maintainers who are determined not to lose control of their packages. (And I do mean "control".) Ian. -- Ian 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 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
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
Tollef Fog Heenwrites: > ]] Philip Hands > >> Tollef Fog Heen writes: >> >> > ]] Ian Jackson >> > >> >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >> >> weeks during which members of the TC have been prevaricating. >> > >> > What are you accusing the TC of lying about? >> >> I think that British English has drifted into using that as a synonym >> for procrastinate while American English seems to have stuck to its >> earlier meaning (judging by the online dictionary entries I see). > > That doesn't match the reading of the Cambridge dictionary: > http://dictionary.cambridge.org/dictionary/english/prevaricate > > prevaricate > verb [ I ] UK /prɪˈvær.ɪ.keɪt/ US /prɪˈver.ə.keɪt/ formal > > to avoid telling the truth or saying exactly what you think: > > Or the Oxford dictionary, > https://en.oxforddictionaries.com/definition/prevaricate: > > prevaricate > VERB > > [NO OBJECT] > Speak or act in an evasive way: > >> I certainly didn't (and still wouldn't) assume that Ian was accusing >> anyone of lying here. > > Given his later apology, I'd assume so as well, but as a native speaker > of English, Ian should really know better than using the term in the > first place. Jolly interesting. It looks like I'll have to add the misuse of that to my list of pedantic pet hates, which is currently topped by 'epicentre' and 'decimate' ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
]] Philip Hands > Tollef Fog Heenwrites: > > > ]] Ian Jackson > > > >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > >> weeks during which members of the TC have been prevaricating. > > > > What are you accusing the TC of lying about? > > I think that British English has drifted into using that as a synonym > for procrastinate while American English seems to have stuck to its > earlier meaning (judging by the online dictionary entries I see). That doesn't match the reading of the Cambridge dictionary: http://dictionary.cambridge.org/dictionary/english/prevaricate prevaricate verb [ I ] UK /prɪˈvær.ɪ.keɪt/ US /prɪˈver.ə.keɪt/ formal to avoid telling the truth or saying exactly what you think: Or the Oxford dictionary, https://en.oxforddictionaries.com/definition/prevaricate: prevaricate VERB [NO OBJECT] Speak or act in an evasive way: > I certainly didn't (and still wouldn't) assume that Ian was accusing > anyone of lying here. Given his later apology, I'd assume so as well, but as a native speaker of English, Ian should really know better than using the term in the first place. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
Tollef Fog Heenwrites: > ]] Ian Jackson > >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ >> weeks during which members of the TC have been prevaricating. > > What are you accusing the TC of lying about? I think that British English has drifted into using that as a synonym for procrastinate while American English seems to have stuck to its earlier meaning (judging by the online dictionary entries I see). I certainly didn't (and still wouldn't) assume that Ian was accusing anyone of lying here. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers
]] Ian Jackson > Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose > maintainers"): > > Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit : > > > 6+ weeks during which members of the TC have been prevaricating. > > > > I had to lookup prevaricate in a dictionary: > > > to speak falsely or misleadingly; deliberately misstate or create an > > > incorrect impression > > > to deviate from the truth > > > > This is not helping, really. Please tone down. > > That's not what meant by "prevaricate". I asked #chiark about the > meaning of the word and they said: They might want to consult a dictionary then, http://www.dictionary.com/browse/prevaricate: verb (used without object), prevaricated, prevaricating. 1. to speak falsely or misleadingly; deliberately misstate or create an incorrect impression; lie. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > weeks during which members of the TC have been prevaricating. What are you accusing the TC of lying about? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > Imagine the roles were replaced. Imagine the actual petitioners (P > and W, for the same of argument) were the current maintainers, and the > actual current maintainer (R) were a petitioner saying "please make me > the maintainer". Would the TC would spend months debating before > dismissing such a manifestly unfounded petition ? That's a very hypothetical question which is hard to answer without more context of what P and W had done lately in terms of maintaining the package. > Can you explain why the TC is so reluctant to depose or overrule > maintainers ? Because I generally find it's generally the wrong tool for the job. If I can come up with a good explanation for why somebody should take a particular course of action (which I need before I'm willing to override anybody), and I take the time to explain it to them and discuss with them, I find we usually end up agreeing. The goal is not to end up with a new maintainer. Deposing a maintainer or overriding them is sometimes a necessary evil, but it's never my first option. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Lars Wirzenius > I suggest a lighter approach than a GR for eroding the strong package > ownership further is to start another page, "LowThresholdHijack" or > something, listing maintainers who are OK if someone hijacks their > package if the maintainer isn't taking good care of it. Would anyone > else than I put themselves on that new page? (If you would, start the > page on the wiki and announce it on this thread, and I'll add myself.) A similar proposal: Have a way of declaring the package to be under collective maintenance (put it under collab-maint on alioth + Maintainer: collect...@debian.org or somesuch?) That'd move closer to a model where individuals don't own that particular package. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote: > I have just created the page: > > https://wiki.debian.org/LowThresholdAdoption > > and added myself to the list. I've added myself to the list. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
Dear all El 05/12/16 a las 19:13, Lars Wirzenius escribió: > We've had the "strong package ownership" concept be a problem in > various ways. Many years ago people were afraid of making NMUs to fix > bugs, even RC bugs, and I started the > https://wiki.debian.org/LowThresholdNmu page. It's got over 300 > maintainers now, and NMUs are quite normal, though I suspect zack's > NMU campaigning helped more. > > I suggest a lighter approach than a GR for eroding the strong package > ownership further is to start another page, "LowThresholdHijack" or > something, listing maintainers who are OK if someone hijacks their > package if the maintainer isn't taking good care of it. I like this idea, although I felt confused about the term. I asked Lars about it in IRC, posting the conversation with his permission: Hi! I'm not sure about what do you mean about hijack, isn't the same as "adoption"? I mean, a maintainer sends a RFA or Orphans a package when she cannot care about it, this is the same, but the initial movement made by a different DD. Isn't it? pretty much. hijack has a stronger connotation where it's done against the current maintainer's wishes, but my proposed list would remove that connotation possibly hijack is the wrong word I don't know if there is a word in English for when the state decides to take apart children from bad (no caring) parents, in Spanish it's "quitar la custodia". That would be the word I would use. If there is not, "adoption", simply, to encourage people to sign in the list. agreed Or maybr just a list of "cat model package maintainers" http://www.trueelena.org/computers/articles/the_cat_model_of_package_ownership.html LowThresholdAdoption maybe? Yes feel free to copy this discussion to the email thread :) Thanks. Will do. Would anyone > else than I put themselves on that new page? (If you would, start the > page on the wiki and announce it on this thread, and I'll add myself.) > I have just created the page: https://wiki.debian.org/LowThresholdAdoption and added myself to the list. I've copied some parts from the LowThresholdNmu wiki page but deleted others (mainly about procedure, because if more people likes this idea, I guess some "procedure" like a NM-RFA should be created? I leave this for the "packaging"(uploading) DDs. I've added myself to the list for one of the tasks I have committed to care in Debian, the coordination of the Spanish translation of www.debian.org. Best regards -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: Replace the TC power to depose maintainers
Ian Jackson <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
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]
We've had the "strong package ownership" concept be a problem in various ways. Many years ago people were afraid of making NMUs to fix bugs, even RC bugs, and I started the https://wiki.debian.org/LowThresholdNmu page. It's got over 300 maintainers now, and NMUs are quite normal, though I suspect zack's NMU campaigning helped more. I suggest a lighter approach than a GR for eroding the strong package ownership further is to start another page, "LowThresholdHijack" or something, listing maintainers who are OK if someone hijacks their package if the maintainer isn't taking good care of it. Would anyone else than I put themselves on that new page? (If you would, start the page on the wiki and announce it on this thread, and I'll add myself.) -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
Russ Allbery writes ("Re: Replace the TC power to depose maintainers [and 1 more messages]"): > Ian Jackson <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]
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
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
Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit : > The bug was filed on the 19th of October. That was nearly 7 weeks > ago. Sure. I'm not saying the TC couldn't be better. > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. I agree with that. > 6+ weeks during which members of the TC have been prevaricating. I had to lookup prevaricate in a dictionary: > to speak falsely or misleadingly; deliberately misstate or create an > incorrect impression > to deviate from the truth This is not helping, really. Please tone down. Frankly, with the timing, content and tone of your meta-interventions around the "recent case" we're talking about, you have just added two more weeks to the process. I now took some time to address these meta-concerns, while I could have have focused on gathering commitments from the actual and prospective maintainers of src:global instead, and drafted a ballot. OdyX
Re: Replace the TC power to depose maintainers
Ian Jackson writes ("Re: Replace the TC power to depose maintainers"): > I still don't understand why the TC is so crushingly slow to conter > maintainer power in Debian. As I say in my other emails, a result of > the TC's inaction, maintainer power in Debian is nearly unassailable. Didier, and Phil, now you're in this conversation: can you explain this to me ? I have a number of theories. Mayber TC members are reluctant to make _any_ decision for fear of making a mistake. Maybe TC members are reluctant to act without consensus. Maybe TC members are reluctant to upset maintainers. Maybe TC members are uncomfortable, as technical people, exercising hard power, and prefer to persuade. Maybe something else, which I don't understand. If I understood _why_ TC members (other than me) behaved this way, it might be possible to frame a GR where the whole project could indicate whether they think this is right or wrong. If I put forward such a GR and lose it, at least I'll know where I stand. There is no point me trying to push this years-long campaign to weaken Debian maintainership (originally, by getting the TC to use its power, but that doesn't seem to be getting much more likely) if the rest of the project thinks that it is just fine that our maintainers are almost completely unaccountable. Ian. -- Ian 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 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
Le vendredi, 2 décembre 2016, 15.42:58 h CET Ian Jackson a écrit : > Hey, I have an idea that maybe you will support, which takes us much > more in that direction and may reinvigorate our existing processes: > > DRAFT GENERAL RESOLUTION STARTS As a general comment, I am in discomfort with GR proposals which have too much preamble and context as part of the decision. Specifically… > OPTION A > > 1. Our priority is our users and free software. > > 2. Debian maintainership is a position of power and responsibility. > It is an earned position, which arises from work and leadership. > Maintainership should continue so long as the good leadership > continues. These two points should be in an argumentary in favour of the actual GR, and not in the GR text. Having the body of developers "emit" that kind of wording (not that I disagree with it…) opens the door to later interpretations, debate about wording, etc. It's uneeded for a GR to re-state that our priority is our users and free software. We have it a foundation document, and re-stating it out of the blue is doing more harm than good, IMHO. > 3. We give advice to the Technical Committee: Giving "wildcard advice" about maintainership, as output of a discussion triggered by "I think the TC will not decide my way", _before_ the TC is just about to take a decision about maintainership, would (as Phil eloquently put it) imply that the project is not trusting the TC and its members to exercise the powers and duties as defined in the constitution. Would that GR pass, I would most probably resign from the TC. That said… the TC's constitutional mandate _is_ up for discussion, it always was, and should always be. It's entirely fine to discuss how the project wants to distribute its powers and duties internally. But if one wants to address how maintainership is handled, emitting a no-op GR giving advice to the TC members is the wrong hammer for that nail, I think. > 4. The Technical Committee should consider all opinions and options > based on their merits, not based on the authority of the speaker. This wording assumes that the TC currently isn't (same goes for further articles. > OPTION B > > (1-6 as above) > > 7. We amend the Constitution section 6.1(4) to remove the words > "requires a 3:1 majority" and "this requires a 3:1 majority". A GR doing that (amending the constitution to lower the TC majority needed when overruling a developer), and only that, would be a strong message from the project upon the importance it gives to maintainership and developers' decisions. I'm not decided whether I like that specific idea or not, but I certainly feel that such a GR would be much less paternalizing to the TC and its members than any flavour of your Option A. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Replace the TC power to depose maintainers
Le jeudi, 1 décembre 2016, 15.46:05 h CET Ian Jackson a écrit : > There is a recent case where: > * The maintainer has done nothing to the package for many years, >other than infrequent (and usually short) emails to NAK >contributions from others; > * The package is years out of date compared to upstream, afflicted by >bitrot, and many users are asking for the new version; > * Several times, proposed updates have been prepared by contributors >but blocked by the maintainer; > * There are new maintainers ready and waiting, with a new package >ready for upload to sid for stretch; > * Now that the TC is involved the maintainer has written many emails >explaining their decisions to NAK uploads, but TC members are >clearly unconvinced on a technical level that those decisions were >right. > Even in this extreme situation the TC has not seen fit to wrest the > package away from the mainainer's deathgrip. I think you're really jumping the gun here. While the TC is not known for acting rapidly, I (would like to) think it is becoming better. In the "recent case" you're using as trigger to this very discussion [0], although some TC members have already expressed opinions (mostly both ways, I feel), the TC hasn't taken a decision yet. It therefore feels quite premature to launch a "Replace the TC power to depose maintainers" discussion. By launching the discussion through assuming the TC will not decide how you think is most fit, you are exercising unwarranted pressure on the TC members who will eventually need to take a decision. You have been on the TC long enough to know how uneasy a TC members' job can be; what about letting those are now in charge with some room ? OdyX [0] #841294, for those not following the tech-ctte pseudo-bug or the debian- ctte@l.d.o list signature.asc Description: This is a digitally signed message part.
Re: Replace the TC power to depose maintainers [and 1 more messages]
Since I didn't want to sent too many more emails, I'll make three short replies in one email... Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"): > We should go for "weak code ownership" instead, which *in theory* is > what we already have Well, no. What we have is a kind of sticky door when the current code owner is cooperative. And many other people have various amounts of influence. The release team have a certain amount of power. But if the current code owner is uncooperative, they have almost absolute hard power. The TC has never desposed an existing maintainer, and very rarely even overturned an individual decision. In the past years the most effective check on absurd maintainer behaviour has been the Release Team, who have functioned in many cases as an effective backstop. This is why we have so many arguments about what counts as an RC bug: If you have tried talking to the maintainer with no success, getting your bug declared RC by the Release Team is the only effective way to get the uncooperative maintainer to accept your patch. > (given every DD can NMU any package), but the > *culture* of strong ownership is so rooted in the project that people > are still too afraid of using it. If you actually do a nonconsensual NMU in this way, ftpmaster might remove your package from the queue. That has happened in the past. That every DD can upload every package is a technical ability, not permission. A DD who uses that technical ability to do the job of the TC (in an act of "civil disobedience" to the Constitution) will usually find that their actions are undone or reversed by the project's other power structures. Normally, as someone who supports the rule of law, I would think that a good thing. But in Debian the rule of law means the rule of the current maintainer. Paul Wise writes ("Re: Replace the TC power to depose maintainers"): > On Sat, 2016-12-03 at 10:27 +, Ian Jackson wrote: > > Mainly, it was a way to control who got email about the package. > > Why was it called Maintainer instead of something more suitable then? Because it's useful to know who to talk to about a package. Frankly, the kind of governance difficulties that arise in a project with many thousands of contributors weren't at the front of our minds... Holger Levsen writes ("Re: Replace the TC power to depose maintainers"): > So I'm wondering, maybe instead of getting rid of the > maintainer field, we should get rid of the uploaders field and allow several > maintainers in the maintainers field? I dunno. We should definitely do this. I don't think it it would be controversial but also I don't think it would fix anything. Ian. -- Ian 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 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
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
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
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
Sheetal Shaliniwrites: > 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
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
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 Wisewrote: > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
❦ 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
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
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
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
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,