Hi!
[ I'm sorry this has gotten a bit long, but I assume I'm going to run out
of time for any discussion, due to the imposed timeline, so I'm trying
to put it all upfront. ]
On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote:
> Guillem Jover <guil...@debian.org> writes:
> > I think the current GR is incorrectly framing the problem at hand,
> > as if it was just an init system selection.
>
> This resonates with me, but...
>
> > I'm thus proposing the following:
>
> I find this really appealing as a higher-level statement of values and
> intent, but unfortunately, I don't think the text does anything to help
> resolve the problems that Sam set out to try and tackle with this GR.
>
> I therefore find myself unwilling to second it, even though on some
> level I would really like to.
I've to say, that while I think I understand where your and other similar
reactions to this proposal are coming from, I also found them a bit
perplexing. :)
Other options
-------------
I'm actually not sure how the other options can be seen as resolving
the root issue at hand. I see what they are trying to do, but I don't
think they are framing it correctly. They are all approaching the problem
from the symptoms, by either trying to go into details on how to integrate
specific stuff, or on how to behave. This all feels like they assume that
people would not respect the spirit of a decision, and to combat bad faith
they need to be very specific on details? But if we'd assume people are
going to be acting in bad faith, then no amount of details and specifics
would fix this, and IMO it can make it worse, as it gives a list of things
to be looking loop holes into and questioning legalities all over. I think
this is a recipe for disaster, and I also find that type of framing a bit
depressing.
The options that favor focusing on systemd still seem to leave the door
open in appearance to alternatives, but in some kind of false sense of
hope way, due to either the proposed vague hopes or all the conditionals
which depend on maintainer discretion to apply based on the (naturally
insufficient) details provided on those options. It seems like a death
by a thousand cuts, which sets the stage for more frustration and
conflict.
The options that favor init alternatives go into specific details (are
these truly exhaustive enough though?). But they still seem to not be
asking the right question.
Let's skim over the other options:
* Option F
- The "cross-distro and standardization efforts" mention feels a bit
misleading to me, as this is really restricted to an ecosystem
based on Linux + glibc + systemd. (To clarify, I think this is
obviously a valid stance to take, I mostly take issue in the way
it is presented.)
- Provides a false sense of hope (see above):
+ "patches _can_ be submitted".
How is this going to prevent the same situations that triggered this
GR?
* Option B
- Provides a false sense of hope (see above):
+ _Should_ include unit and init scripts.
+ Developers and user _can_ explore and develop alternatives.
+ Developers need to provide the work, but that does not imply others
will integrate it.
+ Reviewing and discussing patches but obviously not necessarily
agreeing to them.
How are any of these going to prevent the same situations that triggered
this GR?
* Option A
- Provides a false sense of hope (see above):
+ Focuses on sysvinit specifics like init script, but does not
mention other potentially ancillary features upstream might use
that are not core functionality to the project at hand.
+ The NMU reference looks like a distraction, as it does not fix any
possible deadlock or blocking, as one can always reject an NMU, or
revert it.
+ In Debian, policy (in most cases) follows practice, so whether policy
accepts something does not say much about what maintainers will be
accepting.
How are any of these going to prevent the same situations that triggered
this GR?
* Option D
- Goes into much detail about possible conflicting scenarios, but does
it cover them all? This seems inherently non-exhaustive.
- This encodes very concrete package names and implementation details,
which seem off for a GR.
+ What if the sysvinit maintainers and users agree they want to switch
to something else on top of sysvinit that does not use traditional
init scripts?
- Isn't option D.7 potentially very counterproductive? Mixing regressions
in support with new support seems murky. Also what kind of patch are
we talking about? A 10 liner, or 1 MiB of delta which upstream is not
willing to take, so the burden falls on the Debian maintainers?
* Option E
- What does the "MUST" and "work" in here really imply? Does this mean
every package must fully support natively all currently available init
systems in Debian (runit, s6, etc)? Or say, the day after this option
wins, someone uploads a new brand init system that has no compat
whatsoever with sysvinit init scripts or systemd unit files, then all
init-using packages are then insta-serious buggy?
- As with option A, focuses on init scripts when there might be other
ancillary and minor features used that could be argued to make the
packages systemd specific?
Reframing
---------
Why have init systems become such a contentions and toxic issue? I mean
yeah, it potentially integrates with many parts of the system, but we do
have other components in the distribution with multiple or non-portable
implementations, where we have managed to handle them all just fine (at
least w/o major conflict)? Say http servers, databases, etc., or Linux
specific security frameworks such as SE Linux or AppArmor. We even have
multiple implementations of things like shell interpreters, or awk. The
exact same thing applies to hardware architectures, some of which have
less popcon than say GNU/Hurd or GNU/kFreeBSD!
The way I still see it, this is a project direction issue. The init
aspect is IMO just one (big/important) distraction, but it's still
the tip of the iceberg of the root issue at hand. Until we resolve
that, this kind of clash will keep showing up, in other forms.
I think we have (at least) three clearly delineated camps, with different
expectations. These expectations do clearly clash:
* The traditional-only way camp: This group outright rejects things
like systemd, and other similar technologies. Some of this group was
part of Debian in the past, but found a new home in Devuan. People
questioned why they would go to the extent of purging libsystemd,
which seems to make little technical sense. But one thing it did,
was to set the expectations for what they stand for very clearly.
* Fully integrated Linux camp: This group values offloading integration
to upstream, so that it can be shared by other subsets of the Linux
ecosystem. This group finds supporting portability (software and even
possibly hardware) and alternatives to many of these technologies, to
what could be considered niche, to be a waste of effort and time, and
is not afraid of choosing single implementations (including Linux
itself) within the "plumbing" and across the stack to be relied on,
integrated with and exploited to their full extent.
(I'd say <http://www.islinuxaboutchoice.com/> characterizes a
substantial, if not a majority segment of this group (?).)
* Portability and alternatives camp: This proposal. I see it, as allowing
and welcoming people from both the above camps, as long as they are
open to constructively cooperate, and accept that these both camps
exist, their respective technologies have value, and that there are
people that are fine with using any of these alternatives or at least
supporting them. And that this makes for a richer and more interesting
project with different perspectives.
While I understand the perspective from people that want to focus on a
single technology and/or reject others, I have to confess it feels
rather un-Debian to me. Because it seems like some kind of winner takes
all or scorched earth approach to community building. When we know that
other people value other options too. Also the idea that by dropping
alternatives we will have more person-power to focus on less stuff,
seems to ignore that people that value having alternatives might just
completely disengage from the project, or that we are closing doors to
people that would join the project at large due to some niche sub-project
they have gotten into Debian through. In the end Debian seems to be a
big collection of niches all stitched together.
In my mind, ideally, the two only options on the ballot would correspond
to the second and third camps, which is IMO what the actual current
dispute is all about. My expectation is that by not going into the detail
and deciding instead on the big picture we can set better expectations
and a clear direction for the project at large. Having a clearly
uncompromising second camp option would help with that, and these two
would IMO end the current quarrels, in the same way that when the first
camp found their new home, it seems to have ended a side of that conflict.
Form rationale
--------------
The reason I worded the proposal by defocusing it from the acrimonious
init-specific conflict was in the hope that we can get people to act as
they do when it comes to other areas where we have successfully
collaborated many other times to integrate multiple technologies. As I
mentioned earlier, I think that trying to add some kind of decision tree
on how to behave or collaborate is prone to be incomplete and perpetuate
the behavior we have seen.
Let me give some examples:
* I maintain a Linux-only library (libaio), if somone approached me
with a patch to port it to some other kernel, I'd probably first
check whether upstream is on-board, if upstream would not be, I'd
evaluate the size of the delta, and try to work it out with the
submitter how to proceed. I might take such patch, even if it implies
carrying it for an undetermined amount of time (because I consider
myself a porter at heart), but I think it's equally reasonable to
state that this is a burden that should not be imposed on the
maintainer. But maybe the better approach is to propose to the
submitter to create a new upstream project that provides a
compatible API that can be used on that other kernel.
* Say GNOME decides to go full in on Linux, and lots of its components
start to use non-portable kernel features directly w/o fallback code.
The Debian GNOME maintainers might perhaps decide they want to support
non-Linux use cases, depending on the delta size, or not at all. I
think it's reasonable to not expect them to carry such burden if the
delta size is unmanageable (a consideration that might change from
person to person).
* Or a recent example, llvm shipped kFreeBSD portability patches, the
maintainer (AFAIR) has been forward porting them when packaging new
versions, but at some point these either stopped working or forward
porting them was too much work. A request was made to the kFreeBSD
porters, but no one has (yet?) found the time to handle that, so the
llvm maintainer dropped these patches which were blocking updating
to a new release. If such patches reappear, I expect the maintainer
might have questions on whether this is going to be sustainable in
the future too, and might try to work it out with the porters. I
I think that's also all very reasonable.
* We drop architectures when they do not meet certain criteria, or
decide collectively when some technology has reached its end of
life or has been replaced successfully by other stuff, like with
debiandoc-sgml.
The key here, I guess, is that each situation needs to be evaluated
independently, and no magic decision tree will ever fix trying to work
things out with other people, in good faith, and trying to find
solutions or compromises that satisfy others and us too. But maybe this
is asking too much, dunno. :/
I understand that not giving apparently detailed guidance might make
things more difficult for the policy editors, and I'm sorry about that,
but I think no one ever expected that collaborating in a project such as
Debian with people pulling in random directions would always be easy?
Thanks,
Guillem
