Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
I'm going to make a similar point to Sam's but in a slightly different
way that hopefully will help. (Also, I apologize for sounding rather too
absolute in my initial response to your proposal. There were better ways
of phrasing my concerns.)
Guillem Jover <guillem@debian.org> writes:
> 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.
This isn't how I think about the options. I don't think people are going
to behave in bad faith. Rather, I think the problem is what Sam alluded
to: General statements of principle are more open to interpretation than
their authors think that they are.
With full respect and credit to those who have different goals for this
GR, I personally am largely uninterested in the project making a general
statement of principles about integrating technology. To be frank, I'm
dubious of such statements. I don't think they're always helpful. I also
think the principles of Debian developers are highly diverse (which is
great), and perhaps our goal should not be to try to get everyone in
Debian to align on the same principles, but instead to make practical
decisions that can be supported from a variety of principles.
The problem I want to solve is that we need to make three work-blocking
decisions:
1. Is every package that wants to start a service always, sometimes, or
never required to include an init script? If they are, at what bug
severity and with what consequences if this is not done?
2. Are package maintainers allowed to use systemd-exclusive facilities
that would improve system integration for systemd users or improve
other goals (such as security) at the cost of compatibility with other
init systems? If so, what process should we use for adopting those
facilities?
3. How much effort is the project committing to undertaking to incorporate
alternatives to major systemd ecosystem components (such as elogind)
that are not drop-in replacements, either due to their own
implementation limitations or because our dependency system or other
tools makes drop-in replacement difficult?
As one of the Policy editors, I am primarily concerned with 1 and 2. I'm
only an interested bystander for 3 (ideally Policy should have something
to say here, but we haven't gotten there).
I see huge value in the project making those decisions without regard to
whether the project can agree on principles underlying those decisions. I
don't want to argue about interpretation of some general, non-specific
statement. I want the project to make some decisions.
I believe that we have already exhausted or ruled out other project
mechanisms to make these three critical technical decisions (Policy
process, debian-devel discussion, and the Technical Committee). I think
delegatd teams and the Technical Committee are (correctly!) unwilling to
speak for the project on these closely-divided and highly divisive issues.
Debian is constituted as a democracy of developers. The project makes
technical decisions of last resort via vote.
We've put off this decision as long as we reasonably can, we've tried for
five years to let the discussion calm down and to find some alternative
method of reaching consensus, we've waited to see if some
nonconfrontational approach will evolve, and people are still sniping at
each other. Meanwhile, work that people want to do in Debian, whether
that be better support for non-systemd systems or taking advantage of
valuable systemd features such as ProtectSystem or DynamicUser, is often
blocked on these decisions with no clear prospect for resolution or
unblocking.
You may have noticed in these discussions that I'm not talking about my
own opinion about what the decision could be. I have an opinion, but I've
spent enough energy attempting to convince other people of my opinions on
init systems for one lifetime. On this vote, I'm on team "make a decision
already, whatever that decision is," and the position I'm advocating here
is please do not kick the can even farther down the road.
Towards that end, here are the specific implications of the various
options that I anticipate for Policy. Please note that this is just my
personal opinion as one of the Policy editors. Sean doubtless has his own
opinion and may not agree with me, and we'll sort that out in open
discussion. This is just my starting position.
I'm commenting only on questions 1 and 2 because I don't understand the
intricacies of question 3 well enough to comment, and because I think it's
currently largely outside the scope of Policy.
Choice F:
1. Policy will require packages that want to start services include either
a systemd unit or an init script and will recommend a systemd unit.
Support for starting services under other init systems will not be
required or recommended, but of course may be included if the
maintainer wishes.
2. Package maintainers are allowed to depend on any systemd facility that
they believe is desirable (and, obviously, is supported by the systemd
maintainers) and that doesn't contradict other requirements in Policy.
The Policy editors and anyone else who is interested will start looking
at systemd facilities that may be better ways to do things Policy
currently requires be done some other way and will start changing
Policy to allow or require the systemd facility be used instead when
appropriate and when there are clear benefits.
Choice B:
1. Same as Choice F.
2. Same as Choice F.
(I think the difference between choice B and choice F is largely about
question 3.)
Choice A:
1. Policy will recommend that all packages include init scripts, at least
until such time as the non-systemd community reaches consensus on some
other format for starting services (if that ever happens). In
practice, this will likely mean that Policy will recommend including
both an init script and a systemd unit, because there are various
options that can only be enabled on systemd systems via a unit file and
that I can't in good conscience support Policy not recommending (such
as ProtectSystem).
2. Package maintainers of non-systemd-specific software may not depend on
systemd-specific facilities unless at least sysvinit (currently; in the
future, possibly the major alternative init system should the community
converge on another one) also implements that feature.
Choice D:
1. Same as Choice A.
2. Policy editors and other interested parties will begin looking at
systemd facilities of value and writing Policy specifications for them
following the rules laid out in the proposal. There will be a grace
period of at least six months and no more than twelve months from the
point of agreement on the facility to the point at which package
maintainers are allowed to use those facilities.
Choice E:
1. Policy will require that all packages include init scripts, at least
until such time as the non-systemd community reaches consensus on some
other format for starting services (if that ever happens). As with
Choice A, Policy will probably recommend that packages also include a
systemd unit.
2. Same as Choice A.
Choice G:
1. Policy will continue to be effectively deadlocked here, and thus will
retain the current (confusingly-worded) rule that all packages must
contain init scripts. I personally will likely be sufficiently
frustrated by the lack of clear guidance that I'll steer clear of
init-related parts of Policy and not invest further resources in
reviewing language or trying to find consensus for any changes.
2. Policy will adopt only changes that can reach consenus, which in
practice likely means the same as Choice A except with significantly
increased frustration.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: