Re: Bug#727708: Removal of Ian Jackson from TC
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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: