On Fri, Oct 24, 2014 at 01:32:36PM +0000, Anthony Towns wrote: > On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote: > > On 24 October 2014 13:15, Anthony Towns <aj@erisian.com.au> wrote: > > > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote: > > >> No developer in that chain was compelled to run this under other init > > >> systems. > > > Well, yeah: > > > "1. Nothing in this constitution imposes an obligation on anyone to do > > > work for the Project." > > > Compelling developers isn't something that can be done in Debian. > > No, but we set up requirements that their work must meet before it can > > enter archive or may end up in a release. > Sure, but isn't that just /how/ you compel them? > If you were literally beating people with a stick for not testing their > packages with other init systems, that would certainly be compulsion, no? > Using policy and RC bugs as a metaphorical stick to beat people with > would similarly be compulsion, in my view. Debian never compels anyone to do any work. They always have the option of not doing the work, and as a result, not having the software that they care about being included in the release. You can read this as compulsion if you want, but that's clearly not what the constitution means when it speaks of compulsion, because immediately after stating that no one is compelled to do any work for the project it goes on to say that they are not allowed to work against its rules. And one of those rules is that we can set technical policies for the project by a series of increasingly heavyweight methods, up to and including a majority vote by the full project. This GR comes about because a large number of our developers and users who have not been convinced that systemd is the right solution, or who believe that it is not ready for Debian to adopt *yet* even if it is the right solution over the long term, feel marginalized by the way systemd integration is moving forward. It's clear that many who support systemd balk at the idea they might not be allowed to leverage systemd-specific features in Debian. But if the various imprecations about "encouraging" ongoing support for alternate init systems are to be more than a fig leaf, then this should be encoded in the policy - not left to a thousand individual maintainers and upstream developers, some of whom will wind up painting us into a corner. Policy says today that packages should integrate with the init system using /etc/init.d scripts. The expectation is already there that packages will remain compatible with the least-common denominator *init* interfaces for now. The real problem is when software integrates with a variety of interfaces that are *not* traditionally part of init but are nevertheless bundled with systemd. It's entirely appropriate for Policy to say something about how those interfaces may or may not be depended on in Debian. At the same time that systemd skeptics are feeling marginalized by the systemd decision, systemd supporters are concerned about being prevented from adopting systemd-specific interfaces that they want to use. Well, only one of these groups can be a majority. Either the majority of DDs want us to let software leverage systemd interfaces all the way up the stack, possibly breaking support for non-systemd init; or the majority of DDs want us to hold the line on diversity with respect to init systems, ensuring that new interfaces need to be negotiated with the project in some fashion before being adopted in the distribution; or both of these are minority views. It's a legitimate use of the GR process to find out which of these groups is actually the majority, and to require the project to respect the will of that majority with regards to an issue that threatens to drive deep fissures through our archive and through our community. I don't know which side is in the majority. We know that the TC was evenly split on a choice of future default init system. I don't think I can draw any conclusions from that about what rules Debian wants about alternative init systems. I can say that systemd was my second choice (i.e., not my last choice) as a member of the TC, and that in the aftermath of that vote I believe moving forward with systemd as Debian's default init is the right thing to do. But I'm not even sure how I come down on this particular GR question yet *personally*, because even if I think we should adopt systemd, I have grave misgivings about Debian being tied to an upgrade treadmill by an upstream that may pay little heed to things that matter to Debian's community in the absence of a forcing function. There are very powerful network effects with PID 1. I do not believe that a "do-ocracy" approach is sensible in the face of such monopoly potential. The playing field will always be biased towards the option that bundles more features, whether or not Debian as a whole *wants* those features. Leaving it for sysvinit supporters to play catch-up on features is not a way to decide this matter if Debian's majority doesn't believe it's appropriate to bundle those features in the first place. (N.B.: this doesn't require malice on the part of systemd upstream to be true. It may simply be a difference of philosophy between systemd upstream and the Debian project about what level of bundling is appropriate. That doesn't mean Debian should passively accept scope creep just because it's not malicious.) But whether or not the majority feels this is something that needs to be regulated, we should not be afraid of Debian following the will of the majority. Instead we should be afraid of Debian *not* doing so. Because not voting on the substance of this question, and leaving it to external forces to decide what kind of OS Debian will be in the future, ensures that the same uncertainty, anger and fear that has been distracting us for most of this year will persist for a very long time to come. There are some bad actors on the Internet who will continue to excoriate Debian for any decision they disagree with, and we should certainly not be swayed by those people. But the dissent is not just from the sexist trolls who should crawl back into their cave and let the mountain fall on their knotted heads. There are also a lot of Debian users who are afraid of what the future holds for an OS that they love very much; and they deserve to have that cloud of fear removed from over their heads, to be given closure, even if that closure brings the certainty that they will part ways with Debian rather than being reconciled to it. > Here, things change -- it's worst for everyone if nobody does the work, > but if someone else is doing the work, it's better for you to let them > do it. That's the opposite of the prisoner's dilemma, in that both > non-systemd and systemd users are better off if they "cooperate" by > working on non-systemd support (as opposed to "defecting" by not working > on it), but that's only true given there's compulsion in the first place. > If you compare with and without the compulsion, the only circumstance > that's different is that S is worse off if S and U both choose L, ie > not-working on systemd support. > I'm not sure that the GR proposals actually setup that sort of payoff > matrix, though that's the impression that I get. If it is, I think > "compelled" is a fair description of what's being attempted. It is a form of compulsion that is legitimate under our constitution. There are some times when letting every DD do their own thing is not the right way to build a shared operating system. This may or may not be one of those times; and I'm sure that some DDs will object to any compulsion by the project, whether it's constitutional or not. But I think you've laid out very well how, if one believes this is the OS we want to create, that such compulsion would benefit the project. Being compelled to stay within certain boundaries, and working together toward a common goal instead of treating the archive as a battleground, is not necessarily a bad thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature