Re: support for merged /usr in Debian
Ian Jackson <email@example.com> writes:
> Russ Allbery writes ("Re: support for merged /usr in Debian"):
>> What will kill Debian faster than anything else is to have every idea
>> for changing something large, interesting, or possibly revolutionary in
>> Debian be met with anger, derision, and attacks.
> I know you are engaging in hyperbole, but really, I think this is
> quite unjustified.
I'm not actually intending to engage in hyperbole, and I do think it's a
quite justified fear. Now, there is a legitimate debate about how much
that's actually *happening*, and I concur with your critique that I may be
overstating how much it happens. But I stand by my statement of the risk.
For one specific example, it's become quite clear over the past year that
systemd has achieved the same status as abortion debates in US politics.
Not only is it clear that we will *never* stop arguing about systemd,
opposition to or support of systemd has turned into a tribal identity
marker for at least some people. Those who disagree aren't just
prioritizing different things, or even just wrong, but are actively evil,
horrible people who should be shunned. This is hugely demoralizing and
hugely off-putting. While it is by far not the only thing that has led to
me not spending as much time on Debian over the past year plus, it's
certainly been a factor.
This is obviously one of the biggest examples, but I don't think it's the
only one. There are numerous large and small examples that show up when
people want to change how something has historically worked.
> In the last few years I have embarked on a campaign to change the way
> Debian manages its source code. Of course it's just me, and even so
> it's only getting some of my own effort, so it's not going as rapidly as
> it could.
> But I have had, in general, good support from almost all quarters.
> Almost no-one has tried to discourage me, and there has been no anger,
> derision, or attacks. The main limiting factor has been my own
> available effort, and the complexity of the task.
> Why do you think I have had such an `easy ride' ? I doubt it's because
> I'm popular and everyone just naturally wants to help me.
I believe it's because it's a different kind of change. You're not
changing how Debian systems *work*. You're providing a new tool that can
be used in developing Debian itself.
This has always been much easier, for numerous reasons. One is that we
collectively seem to be much more mentally flexible about our tools than
about OS functionality. Another is that debates over tools don't bring in
as many people who are not themselves currently contributing to Debian
development, but who have very strong opinions about how Debian should
function once installed. And a third is that it's far easier to maintain
a wide collection of tools and let people choose, because tools pose fewer
I was instead talking about changes to the Debian user experience, not
just the stuff we use internally inside the project to produce Debian.
And the pattern I've seen, time and time again, is that someone will come
forward and say "look, I think this aspect of Debian is kind of broken,
and has no real plausible path for getting better, and I think we should
embrace this other way of solving the same problem." And is met by people
who are furious about the fact that the thing that is currently broken is
not being fixed instead of putting effort into something new.
Often we can even get some agreement that the current stuff is kind of
broken, and often they have no more idea of how we can feasibly fix the
current system than anyone else. But the idea of admitting that it's
broken and isn't likely to get any better, or indeed is likely to get
worse, seems to be rage-provoking and produces these huge threads that
degenerate into increasing anger, threats to stop using Debian,
accusations that other people are destroying Debian by trying to improve
it, and so forth.
I think people have the mistaken impression that Marco and a few others
somehow provoke a disproportional number of these arguments. I don't
think they do. I think the difference is that Marco is willing to dig in
his heels and keep reiterating (sometimes not all that poltely, I admit)
the point he's trying to make, rather than backing down and going away.
So you actually notice the argument. If one is less confrontational and
willing to take the flamewar, it's much, much easier to just walk away.
And then there is indeed no contentious argument... and also no one
working on the problem any more, because anyone who was thinking about
working on it looks at that discussion and thinks "wow, I don't want any
piece of that."
> It sees to me that it is because:
> * I haven't been giving talks (or writing mailing list messages or
> manpages) where I attack people's beloved tools, data formats, or
> source code management practices. I could certainly give such
> talks, but it would just serve to make me (more) enemies.
In fact, you *have* done this occasionally. You've been vocal about
things that you think are broken or insane or horrible, using terms like
that. I remember hearing several of them in person. :) For example, I
recall you not being much of a fan of how 3.0 (quilt) packages work.
I think this is entirely natural when you're enthusiastic about fixing
something. People usually don't get excited about fixing something that
they think mostly works fine. It's the flaws that give one motivation to
put a bunch of work into something, and expressing those flaws and one's
frustration with them is a very natural part of that enthusiasm. I think
people should have some understanding of that emotional dynamic.
So I don't mind that you've talked about things that way, and I don't mind
that Marco has talked about things that way. As long as it stays on the
side of talking about bits of technology you don't like instead of people
you don't like, it's not always the best communication strategy, but I
think it's human and natural and partly a measure of enthusiasm.
> I could mention a couple of other projects in Debian that are fairly big
> changes: source-only uploads, and reproducible builds. It seems to me
> that the folks doing those exciting and worthwhile projects are, in
> general, getting support and encouragement from the project as a whole.
> Even multiarch, which is very complicated and was fiercely contested on
> the technical level, has now made it in and even involved relatively low
> levels of aggro - even though on a technical level we are even now still
> working through some of fallout.
Of the projects that you list, the only one that affected how the system
actually works, as opposed to how we do work, is multiarch. And I recall
someone almost resigning from the project over it, and similar angry
threads on the topic. And it's a very minor change to how the system
actually works; the vast majority of users will never notice.
I feel like I understand where you're coming from, and what ideal around
change you're striving for. And certainly the folks working on
reproducible builds have been *amazing*, a wonderful example of how to
achieve change in Debian. But I think the criteria you're applying
strongly discourages people from working on changes to the user experience
in Debian because it's verbotem to ever acknowledge that a current
implementation is not really working for some set of our users, may not be
viable in the long run, or is likely to become increasingly broken. We
get stuck on these really demoralizing debates about how some magical
resources should appear to someone fix structural problems in old systems,
because the idea of acknowledging that they probably won't be fixed and
putting resources into something new isn't an acceptable change.
Another good recent example (well, "recent"; the debate has drug out over
*years*, which is typical) is the Debian menu vs. desktop files argument,
which went all the way to the TC, got a TC decision, and now still isn't
completely settled because there's a separate Policy argument.
I agree that there are amazing people in this project who are able to push
through change to the user experience, de-escalate the conflict, and even
make people feel generally good about the whole process. My point is more
that those people are *rare*, and if that's the bar that you have to pass
in order to work on those sorts of projects, I think we're in trouble.
There are a limited number of people who walk on water in that particular
way, and while our project is blessed with a fair number of them, I don't
think it's viable to expect them to be involved in every change of this
To me, this is far more of a social issue than a technical issue: we're
intolerant of innovation, we're intolerant of enthusiastic people who step
on toes because they're enthusiastic, and we *love* to endlessly redebate
and reargue things in ways that is hugely demoralizing and feels
This is not entirely one-sided. I completely agree with you that
declaring other people's much-loved code or configurations to be dead is
not a good communication technique and contributes to this problem. But I
feel like we have the balance set all wrong here. We're putting all of
the weight of the emotional work and communication on the people who want
to make changes, and that's how a project stagnates.
I'll say it again: enthusiasm is fragile. If we slap down excited people
every time they make intemperate comments out of enthusiasm, we lose SO
MUCH energy. And I don't think we can afford to lose that much energy
from the project.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>