>>>>> "Ian" == Ian Jackson <ijack...@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 <ijack...@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.
