Ian Jackson <ijack...@chiark.greenend.org.uk> 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 integration constraints. 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 sort. 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 hyper-critical. 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
