Re: Tentative summary of the amendments
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.
Looking at it from a game theory approach, assume you've got two groups of
people -- those who use systemd (S), and those who don't (U); and two actions
those groups can take -- work on support for non-systemd init systems (W) or
leave it to someone else (L).
Assume the cost of doing the systemd suport is "-2", the cost of doing
the SysV support is also "-2", and the cost of having the software not
available for you is "-5".
Without any compulsion for systemd folks to work on non-systemd support
the cost grid for a daemon maintained by systemd users who've written
a .service file:
SL SW
UL U=-5 U=0
S=-2 S=-4
UW U=-2 U=-1
S=-2 S=-3
In that case, there is no incentive for systemd folks to do the actual
work for non-systemd stuff -- it's just work for them and no benefit. For
non-systemd folks, there's a benefit to doing the work if systemd folks
don't, and a cost to doing it if systemd folks are doing it anyway. So
the stable solution is for the non-systemd users to do the work of
maintaining the non-systemd support.
If systemd folks are "compelled" (encouraged, whatever) to do the work
to maintain non-systemd support because software won't be included in
Debian if it's systemd only, that matrix changes to:
SL SW
UL U=-5 U=0
S=-7 S=-4
UW U=-2 U=-1
S=-2 S=-3
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.
(You could take the above argument to an extreme and say that policy
should never matter, and everything should end up in the release,
no matter what "bug" it might have. For me, the question is whether
including a package in the distro makes the distro as a whole worse than
not having it. Packages with security holes and data loss bugs match that
criteria for me, while packages that only work with systemd (or upstrart)
don't. If you could imagine including the package in a "kubuntu"-esque
variant of Debian which took the opposite policy and being useful to
users, then I suspect its bugs probably shouldn't be considered RC)
Cheers,
aj
Reply to: