Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Martin Steigerwald - 28.12.17, 13:41:
> This is long, it may invite disagreement, but I tried my best to avoid
> triggering any hurt feelings. In case you just want to be bothered with the
do not want of course.
I proof read the mail several times, but this still slipped through my
> past even for the purpose of figuring out ways to learn from it, I invite
> you to just skip reading the mail. There is certainly no need to relive the
> past. Given current human experience it is also not possible to change it.
> But maybe there is a way toward healing wounds.
> Ian Jackson - 28.12.17, 11:20:
> > Martin Steigerwald writes ("Re: Let's Stop Getting Torn Apart by
> Disagreement: Concerns about the Technical Committee"):
> > > Any workable solution lies beyond blame, however.
> > > Any workable solution lies beyond "I am right and you are wrong".
> > Traditionally Debian has a very workable approach for disagreements
> > over whether software X or Y is better. (For whatever value of
> > "better") Offer both and let people decide for themselves.
> Sure. And it is a good approach.
> Regarding Systemd/SysVInit/OpenRC this approach comes with a considerable
> cost tough as it is such a core part of the system. One cost is that a lot
> of packages link against Systemd library which is part of the reason why
> Devuan exists. Or that GNOME and to some degree other DEs without Systemd
> is somewhat challenging. Devuan developers gave up on the GNOME without
> Systemd topic for now as far as I understood.
> As far as I understand it is not possible without considerable effort and
> quite some of alternative, basically duplicated packages to provide the
> choice of a truly Systemd free system within Debian. It appears to me to be
> almost like a new architecture like FreeBSD or Hurd flavors, not a
> different CPU architecture. Sure Systemd is not an operating system kernel,
> but it is a software that is really tightly coupled with one – a perfectly
> valid, but not the only possible choice made by upstream developers. But to
> provide a new architecture for this would also be considerable, heavy
> overhead. As far as I understand Devuan works a bit like that. They pull in
> a lot of packages unchanged from Debian and inject their own packages with
> some kind of an overlay mechanism. Maybe there is something for Debian
> people to learn from that approach. I did not review it closely so far.
> I think it is partly this limitation that invited most of the uproar in the
> discussion some years ago.
> > When things start to get really emotional and heated is when people
> > feel (rightly or wrongly) that such choices are being curtailed.
> For those who don´t want any part of Systemd installed and used, not even
> the libraries, Debian I think is just not the suitable choice at the
> Providing that free choice would mean to think about ways how something like
> Devuan could be possible *within* the Debian project. Quite a challenge,
> but not impossible I think. Of course, Devuan people may not want to join
> the Debian project, at least not at the moment. On the other hand they do
> not provide Systemd as a choice within Devuan. They just refer to using
> Debian in case one wants to use Systemd. The other way around it could be
> perfectly valid to refer to using Devuan for those who want a Systemd free
> I hope for a time where Debian and Devuan people come together to heal the
> forking. And I mean "heal" literally here. Cause there are still wounds. On
> both sides. Whether there would still be a (officially approved?) variant of
> Debian called Devuan does not matter, it could be a perfectly valid
> outcome. But to heal the wounds… I think that is important work to allow
> for that healing to happen.
> A first step could be to stop accusing each other. Letting go of wanting to
> accuse the other side can help here. I do read dng mailinglists from time to
> time and some main people there often actively ask to drop Systemd debates
> or even hate speech on their lists. As far as I saw they try to be fair to
> Debian packagers as well.
> Within the Debian project a first good step would be to accept the fork,
> instead of just tolerating (and probably suffering from) it (what else could
> Debian people anyway than at least to tolerate it? it is free software
> after all). Accepting the fork basically is just accepting that the past is
> they way it is. Could I let go of wanting to change the past? Especially
> when all my wanting to change the past still was not able to change it?
> I read at least occasionally comments about Devuan in various Debian related
> mailing lists that suggested would not be a long lasting project and there
> would be no capable packagers / developers involved. Comments that tried to
> undermine the relevance of Devuan. A good first step could be to refrain
> from commenting in this way and open up to the possibility that some people
> there are capable packagers and testers as well and that some people have
> there have perfectly valid reasons for doing the work they do. Reasons you
> can think differently about, but still valid reasons.
> Same goes for Devuan people of course. Accepting each other as they are is
> the first big, important step here.
> To come back to the Technical Committee topic: I think it is important to
> appreciate both sides in a dispute even when announcing the final decision.
> I don´t have all the text of the final decisions in mind. I bet tech-ctte
> members care to at least word such a final decision as neutrally or non-
> offensively as they could. But actively appreciating both sides, especially
> the side that "lost" the conflict, may be a step beyond current practice.
> Those decisions are not about right or wrong. They are about technical
> I just reviewed some CTTE decision announcements in debian-devel-announce ml
> and while some of them include at least some rationale about the decision,
> some others are just presenting the result of the decision with strong, but
> accurate wording like "We exercise our power to decide" (including the
> various Systemd ones like 727708 and 762194). I however bet tech-ctte
> members have been completely exhausted after that discussion and decision
> process. So maybe my suggestion to appreciate both sides when announcing
> decisions… is asking for unrealistic super-human powers without other
> changes in the process.
> Also are either not all CTTE´s are announced on debian-devel-announce or is
> [CTTE #741573] Debian Menu System from September 2015 really the last
> technical decision of the CTTE? According to
> it appears that there has not been an technical decision of the CTTE