For the sake of clarity, I'd like to point out that I didn't start this thread solely because of a single IRC log, but rather because of a pattern of behavior over the last year that shows no signs of changing.
On Mon, Nov 10, 2014 at 01:48:42AM +0100, Bas Wijnen wrote: > On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote: > > [CCed to a wider audience, but reply-to and mail-followup-to set to > > avoid a prolonged cross-list thread.] > > > Sune Vuorela wrote: > > > I have a hard time assuming good faith from people who are at war. > > > > Thank you for calling attention to that very disturbing IRC log. I'd > > recommend reading the whole thing, > > I did, and I fail to see what is disturbing about it. I see a TC which > has a good discussion over an emotional subject. And they succeed very > well in keeping it civil almost all of the time. > > > 17:14:02 <Diziet> bdale: The GR is going to be another 3 weeks. > > 17:14:09 <Diziet> We should decide on the automatic switch before then IMO > > What is disturbing about this? We were about to enter a freeze. > Waiting 3 weeks before deciding on an issue which directly impacts the > release doesn't sound like a good idea. How is that controversial? Partly quoting for context, partly showing a general feel of charging ahead, in this case without even respecting the GR process. We can afford to wait for the project to decide how it wants to proceed; if some change needs to happen to deal with this issue, I doubt we'd have significant trouble getting a freeze exception for it. > > 17:15:30 <Diziet> I don't think it's reasonable to say that we need a > > tested alternative given how bad the situation is right now. > > If you think the situation right now is not so bad, of course you > disagree with this. But from his point of view, that this situation is > indeed very bad, there is nothing unreasonable about "let's do > something, anything at all, to make sure this stops; problems we cause > can be fixed". First of all, bear in mind that I helped to revise the draft proposal to flip the libpam-systemd dependencies around (see discussion in bug 746578), and now agree with the finished proposal to do so, so no, that's not why I disagree with that. I also advocated actually testing the result, which Christian Seiler did. I proposed the change in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38 to make systemd-shim safer on systemd systems (by not shipping its own dbus policy), which Steve Langasek agreed with and implemented in systemd-shim 8-4, and someone else noted that cgmanager already avoids running automatically on systemd systems. I do indeed think that there's something extremely unreasonable about charging ahead with an attempted solution without even testing the result. ("We must do something. This is something. Therefore, we must do it.") > > 17:34:12 <dondelelcaro> Diziet: I don't think that stating that we don't > > want to swap on upgrades is something we can agree on > > 17:34:25 <dondelelcaro> Diziet: at least, not while the GR is happening > > which seems to directly address this part of the question > > > > 17:34:28 <Diziet> dondelelcaro: That's not the question. The question is > > whether it's something that would pass a TC vote. > > 17:34:32 <Diziet> I'm done with consensus decisionmaking. > > 17:35:34 <Diziet> That's not to say I'm not open to convincing. But > > everything done by my opponents in this whole war has been done on a > > majoritarian basis and I see no reason to limit myself to consensual acts. > > > > 17:36:48 <dondelelcaro> Diziet: we can always go to majoritarian, but if we > > can agree, so much the better. > > 17:37:17 <Diziet> dondelelcaro: I and my allies have been being shat on by > > the majoritarians since February. It's too late for that. > > Fair enough, this is a part where the level of civility is lower. And this was the main set of items I wanted to call attention to from the log, including the one that Sune originally pointed out. > But > Ian doesn't make an unreasonable point. If those who oppose him are > forcing their side with an overruling vote, why should he refrain from > doing the same? Consensus is great, but if we can't get there, we do > want a decision. And majority is better than nothing. No, majority is not necessarily better than nothing; "nothing" is often a desirable result. You've forgotten to ask whether the TC should be deciding something *at all*. The TC is an arbitration body of *last resort*, not a body that should be frequently acting of its own volition or that of one of its members. Seeking consensus (whether successful or not) is a process that can help discover additional solutions that may prove better than simply taking the first available option that can pass a majority vote. (Also worth pointing out that there's a reason we don't use simple-majority as our voting system. Our voting system in fact explicitly favors options that produce broader consensus; it only devolves to simple majority when we have only two options to choose from.) As dondelelcaro suggested, finding agreement seems quite preferable, and saying "we all give up convincing each other; let's put it to a vote" should only occur as a last resort. Pushing through a vote on an issue as quickly as possible does not seem at all appropriate for the considered actions of a dispute-resolution body. For instance, the libpam-systemd decision ended up reaching a clear consensus. Notice that while there are (or were) four people on the TC opposed to systemd, and four people in favor of it, I've only seen this kind of behavior from one, not four or eight. I've seen far more civility and thoughtfulness by the *maintainer of upstart*, for instance, who if anything would have far more cause to take this issue personally. (See that same IRC log for examples.) Now, to be clear: as an individual developer, having a strong bias on a topic and referring in several issues related to that topic isn't necessarily a problem. I'd fully expect the TC to handle that just fine, and if necessary, to respond to attempted abuses of the TC as well. However, that's a very good reason to have a separation between those referring in issues and those adjudicating them. [Answering both of the next two items together, because they go together.] > > (I'll also point out the pile of #action items Ian self-assigned, > > What's wrong with that? Would you rather see him say "This needs to be > done; someone else do it please"? If the others would disagree that it > needs to be done, they would speak up. That seems to be exactly the > reason he's publishing his intent to do this: to make sure there is > consensus that it is something that needs to be done. > > > as well as the pile of times Ian has effectively self-referred items > > to the TC in the first place.) > > He is a DD, you know? Why would he not be allowed to refer items to the > TC? He could of course ask a friend to do it for him, but that would > just be useless work. He has every right to refer items to the TC. On rare occasion? Sure. Making a repeated pattern of it is a problem, and it starts to look a lot like picking fights (or fighting "bitter rearguard battles"). Someone who frequently feels the need to *raise* disputes should not be serving on the dispute-resolution body. As I said to Don: > I would also suggest that it's a bad idea to let a single member of an > arbitration body refer in a pile of issues, write up draft resolutions > for those issues, push for rapid discussion and votes on those issues, > and send out the resulting decisions. Those do not seem like signs of > a healthy process, and they certainly contribute to the impression of > the TC being used as a weapon. I would hope that that seems sensible to you; if it doesn't, then there's little point in us arguing this further. :) > > I've already felt from the more public portions of the TC discussions > > that Ian has been using the TC as a personal stick to hit people with. > > I don't share that view at all. Ian feels strongly about the issues, > and gets carried away at times. IMO, that is a feature, not a bug, for > a TC member. Already discussed at length above. And no, I don't consider that even remotely a feature for a TC member. (Fortunately so, since otherwise we should be worried that the remainder of the committee lacks that "feature".) > > Calling this a war, > > Have you followed the discussion? This _is_ a war. In much the same sense that emacs versus vi or Linux versus BSD is a "war", sure. Some of us still just consider this a technical issue. That's actually one of the points of dispute, quite frankly: one side believes that this is a technical problem to be solved by technical means (such as developing solutions like systemd-shim, or for that matter entirely better init systems), and the other believes that this is an ideological problem ("loose coupling", etc). I'm not at all convinced that Ian is capable of seeking and sustaining a peace rather than waging an eternal war. I *do* think the other members of the TC are quite capable of seeking peace, and not just the peace of having fully defeated all of one's current opponents. > And not just from > Ian's side: the pro-systemd amendment in the current vote seems to say > "we demand that you trust everything we do, and we don't trust what you > do". When I first read it my reaction was "Woah! That's a declaration > of war!" How anyone could think it would be a good idea to include that > in the amendment was beyond me. That was my initial reaction as well. Then I saw the "bitter rearguard battles" comment, and realized that if the GR doesn't actually make a decisive statement with a strong air of finality, this issue will just keep going on interminably, preventing people from actually getting work done. If this is going to get all the way to a GR, let's have the GR actually *work*. > > To put it bluntly: I don't believe this is even remotely acceptable > > behavior from a member of the TC (or a member of the project in general, > > but in the latter case someone has less potential to cause damage). > > Which part is the problem? That he has a strong opinion? That he wants > to speed this up and get to a decision, even without consensus? Along with the dozen other points above, and along with having basically given up on this being anything other than a bitter war, yes. > The only problematic part I see is that he gets carried away at times. > That's a very minor issue, and I forgive him, as long as he isn't > insulting people. In fact, I not only forgive him; I applaud him for > it; it shows that he cares. > > > Does anyone, in light of the above, feel even remotely comfortable > > having Ian continue to wield^Wserve on the technical committee? > > Not only do I feel comfortable; he is exactly the sort of person I want > there. I'd personally like a few more of Russ on the TC, instead, thanks. Or perhaps a Joey, but those are sadly in shorter supply these days. > > The frothing-mad rampage and the battle-on-every-possible-front needs > > to end. > > Are you saying that Ian started an unprovoked war and just keeps > fighting even though everyone else wants peace? s/war/series of bitter rearguard battles/ :) I'm quite sure Ian wants peace as well, but only expects to have it when all of his opponents are defeated. I think Ian's actions are mostly rational, given an underlying premise of "must win at all costs": fighting a battle on every possible front, leaving no stone unturned, fighting both the battles and the meta-battles, and disrupting any technical work that doesn't align with the underlying vision. And again, for someone *not* serving on the TC, that'd be fine. > > I think it's safe to say that there's a substantial number of > > people hoping that the current GR will actually *settle* this > > question, with the project having spoken. > > Indeed. And I think Ian is one of the first people on that list. See the issue that started this mail thread, regarding "bitter rearguard battles". As Sune said, I don't think it's reasonable to "assume good faith" there and pretend that was really a "oh, other people will probably keep fighting over this"; besides, if it was, it would have applied just as well to both sides. (Unless Ian is specifically suggesting that the anti-systemd folks are less reasonable and less likely to actually accept the result...) > > We clearly have a pile of people who want to discuss and deal with the > > init system issue, many of whom are still capable of productive > > discussion and consensus-building. Many people are actively developing > > solutions to make the situation better. > > Such as "we as TC want to write up a statement; I'll do the work"? Or > is that an unacceptable way of forcing his opinion on others? "we as TC want to write up a statement" already implies that most attempts at productive discussion and consensus building has *failed*. And even then, I expect the members of the TC to actually engage in productive discussion and seek a consensus. And by "developing solutions", I meant actually making useful technical contributions to help support scenarios that people want to run, such as running systems with an init other than systemd, or developing policies for packages using systemd or other inits, or any number of other otherwise helping to make sure everything keeps running smoothly and scenarios people care about keep working. TC decisions don't actually make problems go away; they just decide who wins and who loses. > > What's the procedure for removing someone from the technical committee? > > So let me get this straight; you blame him for abandoning > consensus-building and therefore you want to use a majority-vote for > kicking him out? Seriously? First of all, that's not anywhere close to a sufficient summary of the issues I raised in the mail you replied to. And second: as an absolute last resort, after a year of problems and no sign of them stopping anytime soon? Yes, seriously. Some people help put fires out. Some people start them and throw gasoline on them. We need the former on the TC, not the latter. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110051442.GB4153@thin