Re: Being part of a community and behaving
Theodore Ts'o <tytso@mit.edu> writes:
> That doesn't match my perception of the history; but part of this may
> have been that the vitriol level escalated significantly once the TC
> announced they were going involve itself in the debate,
Yes, we have very different recollections. My recollection is that the
vitriol level actually dropped quite a bit when the TC first started
getting involved, rose (but largely on the TC list) during the argument,
and fell considerably after the decision. Then started to rise again, and
now is worse than it was originally.
> That being said, I am sure that the TC got involved with the best
> intentions, and most of the DD's involved in the discussions were all
> united in their passion for wanting the best for Debian (even if they
> agreed on very little else, at least on the systemd mail threads :-).
> If only everyone could really internalize this belief; I think it
> would make these discussions much less painful.
+1.
> I have a different belief about the future, but (a) there was no way to
> know whether things would have gotten worse back in Fall 2013, and (b)
> there's no way any of us can know for sure what the future will bring,
> or what would have happened if we had taken an alternate path. All we
> can do is to go forward, as best as we can.
In a sense, of course, this is true. However, what I'm trying to point
out is that we have a fundamental governance question facing us here.
What are we, as a project, going to do when we face a decision where the
project is strongly divided and all sides consider the opposing decision
to be a disaster?
Several people commenting here seem to still be stuck on trying to find
some solution that will make everyone happy. Maybe someone will find some
breakthrough, but I have to say that, over the past three years, we've cut
this problem from every different direction and failed to find this. Some
of the attempted compromises have actually made the problem worse. I am
highly dubious that some consensus position is going to emerge.
> Because regardless of how this GR is settled, it doesn't really answer
> the question about the use of all of the other pieces of systemd; or at
> least, I don't think that any of the options are the equivalent of a
> blank check adoption of systemd-*, whether it be systemd-networkd,
> systemd-resolved, systemd-consoled, etc.
Certainly not. Why would we ever say we were going to adopt all upstream
work without even looking at it? We don't do that in any other area of
the distribution.
But one thing that's making this discussion hard is the assumption that
people who *did* take a deep look at a particular component and decided to
use it knowing its advantages and weaknesses somehow were tricked or
fooled by a "marketing campaign" into doing so and didn't know what they
were doing. I find this insulting, and I suspect some of our upstreams
also find this insulting.
Many of the systemd components that you're talking about are, as I
understand it, emerging from work on building lightweight containers,
where it's nice to have an easy-to-deploy minimal stack that can bootstrap
out of nothing, providing just enough support to spawn a process in a
stripped-down, minimal container environment that doesn't need first-class
OS services. That may or may not be the right approach for containers; I
have no strong opinion, having not delved deeply into that space. It's
surely quite a stretch to think that we would adopt components written for
that environment as components on which to build a full-featured OS
installation unless they expand beyond that role and offer clear
advantages and compelling benefits over other components. Maybe they
will, maybe they won't.
> And it sure would be nice if we don't have the same amount of pain as
> each of these components get proposed.
Indeed. Which is, among other things, going to require taking people's
arguments at face value and extending the assumption of good will that
people proposing technical solutions are doing so because they thought
about the problem and thought the solution was superior, not because of a
"marketing campaign."
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: