Hi Jason, I appreciate the intent behind your message and the concern that you're expressing. However, I think lack of context has led you into making a large number of assumptions that are not correct. Since I've seen similar things from other people who are not as familiar with the background and history here, I'm going to use this as an opportunity to try to address some of those misconceptions.
In all of this, one of the things that is worth keeping in mind is that all of us on the Debian TC have worked together for years, frequently know each other from various gatherings, and often consider each other to be friends. There appears to be some concern that we're failing to notice some nefarious motive due to that friendship. I would ask you to consider whether, instead, we're in a much better position, from long familiarity, to judge each other's motives and concerns, and probably have a more accurate judgement of each other's goals than those who are watching this debate from the outside. First off, I can tell you unequivocally that the idea that Ian is pursuing some sort of anti-DFSG agenda or is supporting the Canonical CLA will strike anyone who knows Ian as completely absurd. I can assure you that Ian is quite a bit more annoyed at the Canonical CLA than, for example, I am. There are simply a large number of issues in play here, and it is his judgement that other issues are more significant and the CLA is an annoyance that can be worked around. I completely agree with him on that particular point. Other colleagues on the TC do not. We're a diverse group of individuals who put different weights on different issues, which is why we arrive at different conclusions. My guess is that Ian's feelings about the Canonical CLA are similar to my feelings about systemd's lack of portability: I don't like it, and my ideal init system would not have that property, but I think other things are more important, so it ended up not being a deciding factor in my personal decision. Second, while I understand to some extent the history that gives rise to this concern, I'm really disturbed by the lack of good faith inherent in this idea that there is some sort of Canonical conspiracy in support of upstart. I consider this precisely as toxic as the idea that there is some sort of Red Hat conspiracy to push everyone to use systemd. (And that's entirely apart from the fact that anyone who thinks Canonical, or any other employer, continues to exert some direct influence over Ian's voting doesn't know Ian at all.) For those who are not familiar with the relationship between Ubuntu and Debian, I think some history may be helpful here. Canonical was started largely by long-time Debian contributors who had been responsible for core portions of the Debian project. Those contributors had often accumulated, over time, a large number of projects and ideas that they would have liked to do in Debian, but which were never feasible for one reason or another. One blocker was that no one was paid directly to work on Debian and therefore few people could devote day-job amounts of time to hard problems. Another was that Debian was then, and is even more today, a huge ocean liner of a project with a very bad turning radius. It's quite difficult to make distruptive changes to Debian. Those long-term Debian contributors had a wonderful opportunity in Ubuntu to try a bunch of things that they'd always wanted to do in Debian, to have the time and resources to dig into hard problems, and to push disruptive changes through their entire archive. They had the time to do things like write a completely new init system from scratch, one that, I think it's worth remembering, nearly everyone (including the systemd authors) considered vastly superior to what Linux distributions were using at the time. And, after doing that work in Ubuntu and working through the resulting bugs and instabilities, they were often quite excited about the possibility of integrating that work back into Debian as well. Remember, most early Canonical developers were Debian developers first, and had and often continue to have a great deal of loyalty to and enthusiasm for Debian as a project. I prefer systemd, and presumably you prefer systemd, but I think it's worthwhile and important to take a moment and look at this from the perspective of someone who has had practical experience with upstart in Ubuntu and has done some of the work to integrate it with Ubuntu. upstart is a tested and functional init system which is booting hundreds of thousands of Ubuntu systems. Ubuntu developers have done the hard work of ensuring that it works properly, not with some separate distribution, but with exactly the packages that are in the Debian archive today, at least in sysvinit compatibility mode. Several problems that will be of direct and occasionally unique relevance to Debian, such as boot ordering around ifupdown availability, have already been solved in upstart. It is, from the perspective of Debian packages, a known and tested quantity with which the broader Debian ecosystem has multiple years of experience. Add to that the fact that the upstart source is very well-written, of extremely high quality, and very easy to work with; that there is some possibility (and quite a lot of reason for optimism given the current kFreeBSD porting status) that upstart could be used uniformly across our Linux and non-Linux ports; and that upstart is a small and focused project that tries to do one thing well and has strong support for component-based design and tries not to make assumptions about the other system components. Those are good reasons to favor upstart. They are, at the very least, points about which reasonable people can disagree in good faith. I favor systemd as the choice for Debian, so obviously I think it has other features that are more compelling than those, or disagree with some of those design goals. Making those sorts of value judgements is what we're here to do. But I think it should be obvious that there is no need to postulate some sort of Canonical influence or bias in order to see why others believe there is a strong case to be made for upstart. Where you see people who work for or have worked for Canonical, I see people *who are familiar with upstart*, who know its advantages and disadvantages well, and who have a very good feeling for how much effort is required to work around its quirks. Due to that familiarity, they may understate some of the disadvantages, since they're used to working around them, or understate some systemd features, because they're not familiar with them. But this is not bias; this is well within the judgement calls that we all have to make every day as technical experts. There is no such thing as a completely impartial review of technology, and you wouldn't want someone who was completely impartial making technological decisions since it would indicate a disturbing lack of familiarity with the problem area. In short, you can certainly disagree with the relative weights of the various features or drawbacks of any of the init systems. But I think at the point at which one goes beyond "I disagree" to "and therefore you must be biased," one has lost the plot. This is a hard decision with a lot of subjective judgement, and reasonable people can arrive at opposite conclusions. Finally, a note on the TC decision-making process, since this seems to have bothered a lot of people. I think it's important here to recognize the purpose of formal process in this sort of decision. When everyone agrees, you don't need any process. The sharper the disagreement, the more process-driven everything appears precisely because that's when you need the most process. If you look at any governance process, whether it be legislatures or voting systems or even Robert's Rules of Order, you'll find that 90% of the process is there to deal with the 5% of disputes that are particularly sharp and evenly divided. In other words, paying a lot of attention to small details of process during a sharply divisive decision is not a bug. It's a feature. The whole point of formal process is to provide emotional distance, to focus energies into previously accepted channels, and to fall back on a framework that everyone had previously agreed upon. The goal is to be able to say to your colleagues "I may not be able to trust you to make the right decision, but I trust the process to arrive at a reasonable decision provided that we all follow it." Having that sort of process is what allows groups of people who have to work closely together to get through divisive decisions and still continue to work together. It allows one to invoke intuition about fairness and justice to help push down one's darker emotions and understandable anger when one's colleagues persist in finding unimportant those arguments that we find the most compelling. This is, however, a two-edged sword, and that's one of the most unfortunate parts about the events of this weekend. Because 90% of the process is only used 5% of the time, that process is often not particularly well-tested, nor are the implications as widely agreed-upon as the parts of the process that are followed normally. When one runs across one of these issues where that process has to be invoked, it's not uncommon to run into implications of it that aren't what one expected. For example, in this vote, we were using Condorcet and Debian's standard resolution process as designed when voting on the more complex ballot. But in the course of that voting, we ran across a bunch of tactical corner cases that "felt wrong" to many of us. That was still the process that we all agreed to, but it's not clear that anyone had thought hard about, for example, the degree to which Debian's FD handling fails later-no-harm as a voting criteria. Similarly, and on the other side, the TC has, for a very long time (perhaps always), operated by an agreement that we arrive at an internal consensus on the ballot before calling for a vote. Calling for immediate vote is another part of that process which is there but not used, and it's not clear whether this use of that process was ever anticipated or intended. It's normal and reasonable for people to be upset about things like this! And it's normal and reasonable to fully engage with the minutia of process in very tight and hard decisions because it's a way of channeling one's frustrating and disappointment at not being able to reach consensus into something that nonetheless feels constructive. But the downside of process is that it's a minefield of unexpected twists and turns, and when a procedural move goes against you while you're trying to channel your frustration into process, it's deeply unsettling and it feels like a betrayal. Again, you can see this in real-world situations. Look, for example, at the United States Senate and all of the very heated arguments over cloture votes. Regardless of one's opinion on how cloture should work in the US Senate, one can see from the news that this is something that people get extremely upset about, both when the process is used and when the process is not used. This is even worse in small groups of professional colleagues, where we all have a great deal of respect for each other and normally operate as close to consensus as we can. In that situation, procedural maneuvering can feel like a real personal betrayal. This remains true even if it's achieving a theoretical goal of process: finding a way to reach a conclusion even in cases where the voting body is sharply and nearly evenly divided. This is a lot of text (and thank you if you read this far), but that's because this is a lot of psychology and a lot of nuance. In a lot of the outside commentary that I've seen on this discussion, there has been what I think is a failure of empathy. It's great that people get engaged and interested in technical decisions. I think that's a strength of the open source community. But people should also get engaged and interested in understanding other *people* and finding ways to work with other people in difficult situations, since at the end of the day our communities are about people, not software. And to do that, one has to be able to step back from one's own "side" and put oneself in the other person's shoes and try to understand how they might feel and why they may hold the opinions they do. Bias and conspiracy are easy explanations to reach for, but I don't think they do justice to the richness and diversity of our community. I think it's too easy to assume that someone who disagrees with you, perhaps very strongly, is somehow unethical. We need to be able to disagree while respecting each other's opinions. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
