-project dropped -- no need to spam multiple lists, and -vote seems like the right place for this topic to me.
On 28 October 2014 02:36, Steve Langasek <[email protected]> wrote: > 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 <[email protected]> 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. [then later...] > It is a form of compulsion that is legitimate under our constitution. [...] I don't think you can have it both ways -- either it's a legitimate form of compulsion, and Debian does compel folks sometimes; or neither of those things. I guess the way I'd separate the two is that it's "legitimate" in that it's not making someone do something, but rather preventing them from doing something; and that it's "compulsion" in that it's only preventing them from doing thing A, conditional on them also doing thing B. And Debian does do that sometimes; though I'd argue that's very limited -- and usually involves thing B being much less effort than thing A, and usually directly benefiting everyone who cares about A. For instance, if you package "foo", you also have to deal with security holes in "foo", or put its files in the usual places rather than /opt or similar. However if you package "foo" for Linux on amd64, you don't also have to package it for ppc or freebsd -- you're encouraged to make it "portable", so that someone else will build it for those archictectures automatically, and you're expected to apply patches to fix bugs if users report them, but that's about it. > You can read this as compulsion if you want, but that's clearly not what the > constitution means when it speaks of compulsion, (The constitution doesn't speak of compulsion, it speaks of obligation) What it says is "Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it." That alone is actually sufficient for most RC bug policy: - package "foo" has a whole bunch of buffer overflows and tmp-file bugs and other security things and would need a major rewrite to be remotely secure - Alice packages foo, uploads it to unstable - it's automatically accepted to unstable - security conscious user/developer Bob files an RC bug, documenting the security issues - Alice says people should just use it in trusted environments, and doesn't have the time to try to fix it - release manager Carol ensures the package isn't included in the release Results: - Alice does not need to fix the bug, despite being the maintainer of the package - Carol does not need to include the package in the release If she wanted to do the work, Alice could try creating her own release with different policies to Carol's/Debian's of course. And Dave could come along and actually fix the security holes (maybe working with Alice to maintain the patches in Debian, maybe working with upstream, maybe taking over maintenance of the package, maybe forking the software under a different name). The corresponding question for services versus init systems would be: - package "foo" has a .service file upstream, but no init script - Alice packages foo, doesn't write an init script, and uploads it to unstable - it's automatically accepted to unstable - upstart user Bob files a bug requesting an init script, but doesn't provide a patch - Alice says "just use systemd" and still doesn't write an init script with the question being "does release manager Carol stop the package from being released"? AIUI, policy hasn't ever made not having an init script an RC bug (ie, it says "Packages that include daemons for system services should place scripts in `/etc/init.d' to start or stop services at boot time or during a change of runlevel.", rather than "must place"). So currently, I would expect the answer to be that Carol wouldn't stop the package from being released. > 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. The first step in setting technical policy is coming to (rough) consensus on the -policy list, no? I'm pretty sure that hasn't been attempted yet. (a) That seems absurd to me, and is why I support Charles Plessy's proposal for this GR. (b) Over the past few days I've been working on collecting the various bits that I think should be in -policy; where I'm at is: https://github.com/ajtowns/debian-init-policy I'm hoping to have this at a point to post to -policy for discussion soonish. > 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. I haven't seen any evidence of people actually being marginalised. I've seen a lot of angst when things don't go the way of various opponents of systemd, but that's different to being marginalised. > It's clear that many who support systemd > balk at the idea they might not be allowed to leverage systemd-specific > features in Debian. I'm not sure I've seen people seriously proposing preventing people from leveraging systemd-specific features. Are they? That seems like a bad idea -- I wouldn't expect people to be forbidden from letting their packages take advantage of powerpc or freebsd specific features, just because I won't be able to use them on inux/amd64. openbgpd is only available in Debian for kfreebsd eg, The only packages that are ppc specific seem to be drivers and hardware stuff, but there's a reasonable bunch of x86 specific stuff: I'm writing this via chromium-browser right now, eg. > 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. So, again, -vote isn't the place to get stuff into policy, that's -policy. For that reason, it's hard for me to interpret this is a sincere attempt to update policy. I'm not sure if I should be reading anything into the scare-quotes around "encouraging" or the concern that such encouragement is a "fig leaf". I wonder if what that's talking around is the idea that encouragement isn't enough, and that compulsion is needed. If so, I think that's mistaken -- the current degree of init script support for daemons didn't require threatening to drop packages from the release, and the amount of packages supporting non-x86 architectures isn't due to threats against x86-only architectures. > Policy says today that packages should integrate with the init system using > /etc/init.d scripts. Policy also talks about specifying sequence numbers for scripts in rcN.d directories, which is no longer actually supported afaics... > 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. Sure, and it'd be entirely appropriate to have that conversation on -policy. Having it on -vote (or on -ctte) makes it seem less like it's about having a conversation, and more like an attempt at coercion... > 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. Per popcon, amd64 is the majority architecture; I don't think we have a problem with amd64 supporters using (or being prevented from using) amd64-specific interfaces, even if that does mean that people who care about non-amd64 architectures have to put in a bit more effort -- for instance, actually providing porters who care about glibc and gcc, rather than just relying on the primary maintainers of those packages. > 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. I guess you think you're intending to apply the law of excluded middle there, but to me it looks more like a false dichotomy. Personally, I expect a majority of DDs want to /both/ allow packages to leverage all of systemd's features, while also supporting a diversity of init systems for sysadmins to choose from. > 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. Sure, and it's a legitimate use of the tech ctte to get a ruling on an issue. But just getting a ruling from a committee, or a majority vote from the project (or a course change from a SABDFL) doesn't mean anyone will necessary end up agreeing with decision, or necessarily respect it. > 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. (Actually systemd was your third choice; FD was your first choice) > 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. That seems like unnecessarily loaded language. A "do-ocracy" approach is completely feasible -- worst case, you can fork Debian and *do* whatever you like, with or without systemd. It's provably feasible, because it requires no more work than the combination of systemd upstream, Debian maintainers and software upstreams are already doing. cf Ubuntu and XFree86, for instance. PID 1 has two important features: when it dies, so does the system, and it gets notifications about double-forking zombies (or some such). Those are important for various reasons, but they're not amazing network effects. I don't know how bothersome systemd upgrades and backwards compatability is; if it /is/ a problem, that's something Debian probably can and will solve for our users; and I don't think it's anything special for people who don't use systemd. As an amd64 user, I'm not particularly bothered by the changes to ARM ABIs, for instance. > The playing field will always be biased towards the option that bundles more > features, I don't think that's particularly true; though it may be that the option the marketplace most favours has the resources to bundle the most features. > whether or not Debian as a whole *wants* those features. Debian's a group, not an individual -- many of its members want things, but I don't think it's really meaningful to talk as if it has a single desire. For just about anything that a majority wants, there'll be a minority who want something different, and maybe the exact opposite. And for most members of Debian, they'll be in the minority for something they care about a lot. (Free software and happy users being the obvious two exceptions) > 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. I don't agree; I think that's *exactly* the way to resolve things. Just as I'd expect the folks who care about amd64 (hi Intel!) to play catch-up on features when arm starts doing something cool that people like. That doesn't mean everything has to do the same set of cool things -- it's perfectly reasonable for people who care a lot about running an email server to use postfix or exim, while still supporting ssmtp or nullmailer for people for whom extra features in a mail server are actually annoying. > 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. I'm not convinced I agree with this; on the contrary, I'd say Debian supporting lots of different approaches simultaneously is a lot better than Debian just supporting the approach a majority of people like. (I wouldn't call having five implementations that all do exactly the same things to be "different approaches") > 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. Honestly, I haven't seen that much uncertainty, anger or fear since the ctte decision. I would have described things as "Debian's going with systemd, but other stuff should still work. Most people are moving on." As far as uncertainty goes, the lack of any actual policy updates on the topic since the ctte's decision about 9 months ago is where I'd assign lay the blame. > 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. And that's the only "anger and fear" I've seen. Yet, you just talked about "uncertainty, anger and fear" as something that should motivate this GR... > 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. Did you really need to call *anyone* who cares enough about Debian to post their opinions any of those things? > 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. Are there? Has there been a poll somewhere? Are you just projecting your own concerns? Or...? Are there also a lot of Ubuntu users who feel exactly the same way about its switch to systemd? > It is a form of compulsion that is legitimate under our constitution. Alternatively, "it is a way of violating the spirit of the constitution while obeying the letter". I don't think saying "if you want to package a systemd service file, you have to also package an init script or your package won't be part of a Debian release" will cause a constitutional crisis. It would take the release team deciding they'll deliberately not enforce that rule for that to happen, and I doubt they care enough to go that far. I don't think you can fairly call that something other than attempting to create an obligation on developers who only care about working with systemd (and to some extent the release team too), though, and I don't think that's in line with the spirit of Debian. But hey, I get to have my conception of what Debian's about, and you can have yours, and even if they're different we both still get to install it as many times as we want. [game theory analysis] > 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. The analysis I did had four scenarios considered with and without compulsion. In three of the scenarios, everyone had the exact same payoff with or without compulsion. In the remaining scenario, the systemd users were worse off by 5 points, and the upstart users had the same payoff. That is to say, from the point of view of the analysis, in *no* circumstance was anyone better off, but rather, systemd users/developers were worse off in one case. Further, if you assign equal weight to systemd and non-systemd's payoffs [0] then the three invariant scenarios are all of equal social utility. For the payoff matrices I presented, the nash equilibria are (SL,UW) without coercion, and (UW,SL) or (UL,SW) with coercion. The scores for that are A: U=-2, S=-2 B: U=p(-2)+(1-p)(0), S=p(-2)+(1-p)(-4) where p is the chance of the UW,SL equilibrium happening. Simplifying B, B: U=-2p, S=-4+2p so S is worse off in B by (2-2p) points, while U is better off in B by (2-2p) points. ie, B is better than A exactly when you think improving things for non-systemd folks outweighs harming systemd folks. [0] ie, -2 for systemd is precisely as bad as -2 for non-systemd -- you might not want to do this if there are more systemd users/dev than non-systemd users devs, eg. I don't think I can see a reason why non-systemd users should be weighted more heavily than systemd users (unless the person doing the weighting is one themselves, and is being deliberately biassed of course). There's also an alternate action systemd folks could take, namely actually packaging "uselessd". Call that SX. The payoff matrix for that might be: SL SW SX UL U=-5 U=0 U=-5 S=-7 S=-4 S=-3 UW U=-2 U=-1 U=-2 S=-2 S=-3 S=-3 I'm obviously assuming that (a) packaging uselessd is less effort than maintaining init scripts for all the systemd-only services we're imagining exist; (b) that packaging uselessd is less of a bother than just ignoring all the systemd-only services. The nash-equilibrium in that case would still be just UW,SL by my count. (U prefers UW,SL to UL,SL; S prefers UL,SX to UL,SL; U prefers UW,SX to UL,SX; S prefers UL,SL to UL,SX) Games like this aren't realistic though, in at least the sense that in the real world you can do things outside of a game. Like having someone who only uses amd64 actually care about arm or ppc just because it's fun, or because they owe someone who uses arm or ppc a favour. Or by having someone say "if you defect, sure you might win in this game, but you'll be punished in the afterlife [1] and that'll be much worse!". [1] or next time we play a similar game, etc (As is probably implied by the construction, I guess I'd say UW,SW would be the "best" position in the payoff matrix, but I also tend to think that it implies the U folks would owe a favour to the S folks as a consequence. Of the "hey, thanks for handling those init scripts, I know it's a pain. BTW, check this out: I fixed the bug in printing that you mentioned the other day!" kind) > 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. If you've actually got a common goal, I don't think working together requires "being complled" to stay within "certain boundaries". (I think we (ie, DDs in general) do have a common goal here) Cheers, aj -- Anthony Towns <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/cajs_lcur9sbf1qqtdbktg07yz-3mlof8mekjy42p2ootcdj...@mail.gmail.com
