Re: [draft] Draft text on Init Systems GR

[Sam Hartman <hartmans@debian.org>]

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:


    Ian> The patterns I am trying to address with this are things like:

    Ian>  * Vague RC bug reports against pieces of the non-systemd
    Ian> ecosystem, which do not actually describe a particular bug, or
    Ian> an approach acceptable to the submitter, and are therefore
    Ian> unresolvable.
 
    Ian>  * Maintainers of key packages declining to relax strong
    Ian> dependencies on systemd components on the grounds of fairly
    Ian> marginal differences in functionality when a non-systemd
    Ian> alternative is chosen.

    Ian>  * Declining to accept init scripts, or arguing against the
    Ian> inclusion of init scripts, on the grounds that they should be
    Ian> properly tested by the maintainer and the author doesn't
    Ian> consider testing them to be a good use of time.

    Ian>  * In general, blocking the work of non-systemd contributors on
    Ian> the grounds that the arrangement that the non-systemd
    Ian> contributors are trying to create for non-systemd users is
    Ian> somehow suboptimal or broken, in the opinion of the
    Ian> systemd-supporting gatekeepers (be that maintainers, members of
    Ian> the release team, or anyone else).

    Ian> It is really unfortunate, but I have seen multiple examples of
    Ian> each of the first three specific patterns above.  IMO we must
    Ian> address this.

I strongly agree.
I've also seen non-systemd contributors being
inappropriate--disrespectful, abusing the BTS, and generally not being
excellent to each other.
I understand in the past you can probably find examples of systemd
contributors doing that, and certainly I've seen the pattern of
doomssaying about the longterm viability of non-system solutions.
Today though, systemd contributors seem to block or produce vague  and
unactionable objections when they are being obstructive.
Non-systemd contributors find themselves in a position of anger and
probably fear and seem to be lashing out in frustration.

I want to stress that I'm not judging anyone--not either side.  I
understand how we get to this point.
But I strongly believe we must stop this behavior.  We should figure out
which work we're willing to do, do that work professionally, and
politely decline the rest.
It sounds like we share that goal, even if we see the approaches to get
there differently.

I think that the DPL, the TC, and anything the TC might evolve into will
be critical forces in moving forward after the GR.  For me as DPL, the
big question is which direction to go to resolve the pattern.

    Ian> How about:

Yeah this is much better.

I do have a suggestion that I've included below.
 we close in on intent.
 My wording is not great, but we can refine wording after

    Ian>   Maintainers of systemd components, or other gatekeepers
    Ian> (including other maintainers and the release team) sometimes
    Ian> have to evaluate technical contributions intended to support
    Ian> non-systemd users.  Such contributions should be accepted, even
    Ian> if they are or may be of compromised quality, if the
    Ian> quality/risk is acceptable to the maintainers of non-default
    Ian> init systems and the surrounding community
    sh> and the risk will be born by the users of non-default
    sh> initsystems.  To the extent that the risk will be born by users
sh> of default initsystems, normal procedures for judging
sh> acceptable risk should be used.

    Ian> Ian.

    Ian> -- Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions
    Ian> are my own.

    Ian> If I emailed you from an address @fyvzl.net or @evade.org.uk,
    Ian> that is a private address which bypasses my fierce spamfilter.