Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
-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 <vorlon@debian.org> 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 <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.
[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 <aj@erisian.com.au>
Reply to: