Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > Are the protocols offered by systemd and upstart each so plainly
> > reasonable, that we are willing to overrule a maintainer who feels they
> > protocol they are asked to support is too ugly or burdensome ? Are such
> > a maintainer's objections so unreasonable ?
>
> Ah, okay, I see what you're getting at.
>
> 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.
> My inclination would be to give maintainers technical advice to
> accept integrations with either existing synchronization protocols,
> but leave it as technical advice rather than the binding part of the
> decision.
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.
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.
If we signal now what we would think of such a situation then this
will be less likely and if it does happen it will take much less long
to resolve.
(The same scenario might occur the other way round, although
currently the systemd maintainers have rejected the proposal to
support upstart's readiness protocol.)
> > It also includes the important point that it is up to the maintainer to
> > justify non-inclusion, not the other way around.
>
> I guess the question here is how many conflicts we anticipate and whether
> it's worth being somewhat confrontational ourselves to head it off. If
> there aren't conflicts in practice, we're just creating conflict without a
> need. I don't think it matters a tremendous amount, though.
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 don't agree. Unless we either have a compatibility shim, or a policy
> > decision to transition, every package ought to be required to provide
> > something in the Debian menus. Isn't this situation analogous to the
> > mime-support argument where we required a package to reinstate a mime
> > entry ?
>
> Sorry, I didn't state my objection very well. I wasn't talking about
> packages removing menu files.
>
> Rather, your original wording to me sounds like introducing support for
> desktop files in Debian would violate this guidance unless the one
> introducing that support went through the Policy process first, even if
> the new support did not conflict with menus and did not break anything
> about menus. That seems wrong.
Perhaps my wording needs improving. The problematic step is not the
introduction of a parallel system. The problematic steps are:
* Stopping providing menu files in existing menu entry providers
* Existing menu consumers stopping offering a way in the UI
to access the Debian menu system menu
* Justifying the above two steps on the grounds that menu is
"obsolete"
All of these have happened, without a proper consideration of
(a) the goals of _all_ the users and admins who rely on or use the
Debian menu and how those goals can be met with the new arrangements
and (b) a proper transition plan.
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.
We have unfortunately seen this same pattern more than once. The
evince mime entry is an example. The bug report requesting that Colin
disable binfmt-support when systemd is installed is another.
> In other words, just introducing something that is intended as a
> replacement for some existing Debian functionality should not require
> coordinating with anyone. What requires coordination is the point at
> which the new functionality starts breaking the old functionality, so that
> the project as a whole can decide that either we need to do something else
> or that the old functionality isn't important and it's fine to break it.
Yes.
I shall try to reword this part to make this clear.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
