[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

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

Reply to: