Matthew Vernon <matt...@debian.org> writes: > I wish to propose the following general resolution, and hereby call for > seconds. I don't think further lengthy discussion of the issues is > likely to be productive, and therefore hope we can bring this swiftly to > a vote so that the project can state its mind on this important > issue. The substantive text is that which was drafted for the purposes > of the technical committee's vote (where they decided not to pass a > resolution on the subject).
I sent this just now to the TC bug in response to a message from Colin, but since this GR conversation has started, it's probably more useful here instead. In general, the TC has spent months talking about this, and I've said rather more than my fair share on the topic, so I would rather let the rest of the project have their turn and largely stay out of this GR debate. But I'm not sure that I ever coherently presented, in a single message, my core argument against the text that Matthew has now proposed as a GR. That's what this message is. I'm happy to discuss it, particularly to clarify. I'm going to try to limit my involvement in the other branches of the debate, in part because I'm a bit burned out on the whole conversation and in part because I think I've already said my peace. Since, in my opinion, this question is all about how the project wants to govern itself and how we want to handle assigning responsibility for work that we think should happen, I will be very interested in general project discussion and, if there are enough seconds, voting on this topic. It's possible that my impression of how the project should work is at odds with the project as a whole, which would be a valuable course correction for me. Anyway, here it is, with a few minor edits upon re-reading it: I want to reiterate here, since it's easy to lose in the long discussions, that I completely agree with the sentiment. I like the idea of standardized services and interfaces, I like having the flexibility of multiple implementations of those services and use that flexibility quite a bit myself. I would generally prefer for multiple implementations to be possible in any case where there are multiple ways of going about something. However, I also don't think those principles were ever what this debate was about. I don't think we'll find much disagreement with those as general principles. The question that is before us is not whether we approve of standard interfaces and multiple implementations. Everyone who has spoken up on this topic has indicated support for allowing multiple implementations of standard interfaces. Rather, the question that was before us was about the error case. When circumstances arise where those multiple implementations do not exist, who bears the burden of creating them? The position of loose coupling is that the Debian contributor who wants to package a piece of software is responsible for porting it to every major init system. The position for which I was advocating is that the people who are interested in having software run on the non-default init system, which *may* include the Debian contributor who is packaging it but *might not*, are responsible for the porting work, and that packaging of the software for Debian should not necessarily block on that work being completed. In other words, I'm advocating the same position that we have right now for translations: the package maintainer is not expected to translate their package to other languages, but they are expected to incorporate translations as they are made available. The translators bear the burden of the work for doing the translation, and if no one steps up to translate a particular package to some language, it won't be available in that language. To take the specific example of GNOME, in a world in which there are multiple implementations of logind that satisfy the same interface, there is no conflict here. I want to keep reiterating that, since it seems like people keep thinking they're at war with others when no actual conflict exists. The GNOME maintainers have already said they'd be happy to allow alternative dependencies, the systemd maintainers have already said they'd be happy to work with the providers of alternative logind implementations to sort out the proper dependency and package structure, GNOME upstream has said that they'd be delighted for such a thing to exist, and everyone would be happy to have this in place by jessie. We're all a big happy family on this point, even if some of the people in the back seat can't stop poking each other. :) *All* of this argument is over what happens when those multiple implementations don't actually materialize. My continued objections to loose coupling is that I think it makes the wrong choice in that contingency, and I think it does so in a way that's destructive to Debian as a project. I believe the loose coupling proposal has the effect of trying to force Debian contributors to care about something they don't necessarily care about as the bar to entry in the project. Now, that is appropriate to some extent, since the goal of Debian is to create a distribution, not a random collection of packages. But historically (and this line is what Policy is *all about*, so I've had a lot of practical experience with it), we've tried to limit the places where we make this sort of requirement to two types of problems: places where the package simply has to work a particular way or it won't be functional or may break the rest of the system, and places where the amount of effort required for the maintainer is reasonably small. So, for example, if you package a shared library, you have to care about shlibs or symbols, SONAMEs, and library package naming. That's just the way it is; we rely on those mechanisms to make shared libraries work properly, and your package is broken and will break other things if you don't follow those rules. Or, for the second point, your package should not strip binaries if DEB_BUILD_OPTIONS=nostrip is set. This is generally quite easy to do, and normally the standard tools do it for you, so there aren't a lot of good reasons for not supporting this. Porting GNOME to something other than logind, or implementing logind without its various systemd requirements, is neither of these things. It's not something that has to be done or the packages are simply broken, as demonstrated by the fact that they would work fine with the default init system (which was, at least as far as I'm concerned, chosen for different reasons than this whole argument). And it's not a small amount of work. If people do the work, great! Everyone thinks that's great, as noted above. We define a virtual package that provides the necessary interfaces, multiple maintenance teams happily maintain multiple implementations going forward, and we move on with our lives. We all hope that's the situation that we end up in. But when providing project-wide guidance, we have an obligation to worry about the error conditions as well. If multiple logind implementations do *not* materialize, or if they do materialize but then people lose interest or run out of time and stop maintaining them and they stop being viable, loose coupling says that the burden now falls on the GNOME package maintainers to do all the work to write or maintain an alternative logind implementation. For init systems they don't use or for systems they don't use. That's not cooperation and coordination and working together. That's holding someone's work hostage to try to force them to do (substantial) work that they're not interested in. I think it's directly contrary to the spirit of section 2.1.1 of the constitution, and it makes me very unhappy. We all want there to be multiple implementations of standard, reasonable APIs so that we can choose software based on its merits and not because it's the only implementation of a useful interface. We also all live in the real world where that doesn't always happen. The work doesn't magically accomplish itself. Someone has to care enough to make it happen. If no one cares enough, then I think we need to recognize that maybe having multiple implementations isn't important enough to motivate anyone to volunteer to do it, and therefore we'll have to live without the benefits of having them. If that feels like an unacceptable outcome, well, I think the right reaction is to go do the work so that this outcome doesn't arise. Not to try to write project rules to force other people who are less interested in the work or who may not agree with the acceptability of the outcome to do the work on our behalf. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87bnxogyq9....@windlord.stanford.edu
