Bug#727708: init system discussion status
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> I think they are. Furthermore, I don't think there's any likely
>> prospect that either will adopt a socket-based synchronization protocol
>> other than systemd's, so saying that these aren't patches maintainers
>> are required to take pretty much says that maintainers aren't required
>> to integrate with the synchronization protocols.
> In practice I think, given the political context, almost every daemon
> maintainer (or upstream) will be willing to provide at least _one_ of
> current the upstart and systemd protocols.
> I don't see any value in insisting that every daemon maintainer should
> support both, perhaps against their will, when supporting both protocols
> in each of the perhaps six init systems will be much less work overall.
>> We could do that. In general, I'd really prefer to defer to
>> maintainers on what they're willing to integrate with. [...]
> So in that case you're saying you wouldn't want to overrule a maintainer
> who declined to provide either of the currently available protocols.
> Which seems to be the opposite of what you say above.
Yes, I know, I'm being confusing. I'm sorry about that. It's because I'm
trying to balance two different goals, which are in conflict here. One is
that I prefer to defer to maintainers on how to maintain their own
packages. The other is that I think we all have some obligation to let
other people work on things they care about if it doesn't cause disruptive
impact on us.
I think the wording path that you're going down right now requires us to
take a firm stand one way or another, in advance, on what we're going to
tell the whole project to do. I consider telling people what to do to be
an inherent problem, although sometimes an unavoidable one. The more I
think about this, the more I prefer to give maintainers the technical
advice that they should integrate with any init system that is being
actively developed, provided that it doesn't have a negative impact on
their package, and leave it at that.
If we have to decide whether to override a maintainer on whether to
support a non-default init system, well, we'll have to decide that, and it
will be unpleasant. But I'm not sure we need to proactively dive into
that unpleasantness.
> Of course formally all of this is just advisory, because no specific
> example is here yet. But I take you to mean that you don't want to
> signal that we would overrule maintainers in particular circumstances.
Right.
> Let us suppose that we don't say anything in particular about what
> maintainers are expected to do. (I'll also suppose WLOG that the TC
> collectively votes for upstart as default.)
> I would expect the following things to happen, then: upstart would get
> sd_notify support; an upstart contributor send a patch adding an upstart
> job for a daemon package which already supports systemd; the daemon
> maintainer rejects the patch; the upstart contributor refers the matter
> to us.
I'm not sure why you think the "daemon maintainer rejects the patch" part
of this is likely, particularly if upstart supports sd_notify, which makes
the patch basically trivial.
I don't think this is a likely conflict. A much more likely conflict
would be that upstart is adopted as the default init system, a daemon is
patched to support raise(SIGSTOP), a systemd contributor submits a patch
to support sd_notify (or socket activation), and the daemon maintainer
rejects that patch.
I personally think that such a patch should be accepted. But I don't know
that I'm willing to say in advance that we're going to try to force that
patch to be accepted. So I'm good with offering technical advice to
accept such patches, but not with signaling that we're going to override
people who don't.
> It is always easier and less personal to have these conversations in the
> abstract, before particular people have got upset about the specific
> question.
> I really think we should decide in advance some ground rules for what we
> would and would not be willing to force on a maintainer.
I consider the TC, when working properly, to be like a court, not an
executive or legislature. I therefore prefer focused and limited
decisions for the same reasons that court decisions try to err on the side
of being focused and limited. That doesn't completely rule out your
point, of course; courts, particularly high courts, set these sorts of
guidelines for evaluating future cases all the time. But I'm not seeing
it as obviously necessary here.
> No matter how creaky and obsolete the Debian menu system is (or is
> thought to be in some quarters), that's not the way to go about things.
> It causes significant technical problems, and it's also very rude.
I would be more comfortable with this argument if we had a working Policy
process that could reach these conclusions in a timely fashion. It's been
obvious to me that desktop files are a better (and, more importantly, more
widely supported) representation of this information for over six years
now, but given that I, as a Policy Editor, don't know how to effectively
get there from here, I have a hard time blaming the GNOME and KDE
maintainers for not knowing either.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: