Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +0000, Anthony Towns wrote:
> > 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
But this GR has effects beyond anything that could be reasonably
described as a general technical policy. It prohibits even leaf packages
that offer functionality to the majority of people, unless the
maintainers do possibly significant work for the benefit of a certain
minority.
Would you consider it as purely technical policy if Debian tried to help
the adoption of better programming languages by forbidding any program
implemented in PHP unless there's an equivalent program implemented in
another language, or forbidding packaging of Perl modules unless an
equivalent module was available for Python?
> 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.
IMO the above could be a valid justification for *a* GR, but it does not
really apply to *this* particular GR proposed by Ian. There is no clear
"leverage systemd interfaces all the way up the stack, possibly breaking
support for non-systemd init" option for systemd supporters to select.
The anti-systemd option is not "ensuring that new interfaces need to be
negotiated with the project in some fashion", but strictly sticking with
the obsolete sysvinit, no room for negotiating any upgrades.
> 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.
If you have concerns about the *future* development of systemd, is
sticking with sysvinit-level functionality like this GR really a sane
answer? Even if systemd development goes in a direction Debian does not
like, why wouldn't a fork of systemd be a better answer to that? It
shouldn't be too much work to maintain a fork if it's only required to
work better than sysvinit.
> 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
Systemd developers are making fast progress implementing several
positive features that are desirable for Debian too. It does not really
matter whether the majority believes it's appropriate to bundle those
features with each other (or with other features that people don't care
about) if there is no realistic plan to implement an at all comparable
level of functionality without such bundling. "Biased" playing field or
not, if one side gets a huge amount of useful functionality working and
the other has nothing, trying to declare the latter side a winner only
makes you ridiculous and/or irrelevant. And I don't believe that you
could get a large amount of sysvinit work done by "you must work on this
or we break your other work" threats.
> 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.
As described above, it seems unlikely that *this* GR would bring
closure. Even if Ian's proposal loses, I doubt it will silence people
who demand that people do more work for the sake of non-systemd inits.
Reply to: