Re: Proposal: General Resolution on Init Systems and systemd Facilities
Russ Allbery writes ("Re: Proposal: General Resolution on Init Systems and systemd Facilities"):
> If we're going to expect there to be a transition period, I would prefer
> the time be defined, rather than left for case-by-case argument. If folks
> would prefer that we have zero delay (as soon as Policy standardizes a
> facility currently only supported by systemd, people can start using it
> immediately), that's viable from a Policy perspective.
ISTM that a zero transition period would contradict the requirement,
which Holger and Thomas propose to retain, that "the transition should
be as smooth as possible for all users including those of alternative
init systems".
It would also put non-systemd folks in the position of needing to
block (or delay) policy development simply to give themselves
implementation time. Ie, in practice it would require systemd
sceptics to engage in bad, perhaps even disingenuous, behaviours.
Thomas writes:
I agree with Holger that it's probably better to leave the amount of
time undefined, and see what happens on a case by case basis.
So I guess that's not what he wants.
> But it's hard (and not particularly fun) work on Policy to decide a
> reasonable non-zero delay on a case-by-case basis for every feature.
Exactly.
> Ian's text says that we always introduce new feature descriptions and then
> pick something between six months and a year before people get to start
> using the new thing, and provides an easy out that in the case of
> disagreement we can just always pick a year and be done.
>
> This may slow progress, but it removes a point of argument, which is very
> appealing.
Of course if the (re)implementation(s) of the (new) interface are
complete before the time is up, there would be no reason to continue
to delay, and blessing immediate use would be uncontroversial.
So the delay in my text is a maximum, not a minimum.
And I just want to reset the framing:
There is of course nothing stopping advocates of the new interface,
who are happy with systemd and want to see faster progress, from
helping out with the implementation. Normally that is how we would do
things in Debian: the people who want to change something have to do
that change. Even for things that the project as a whole is extremely
keen on.
Shifting the implementation burden to the community around non-default
init systems is a key part of the compromise embedded into my
proposal. But that does mean that the precise terms of the compromise
need to be in the GR, to avoid continuing debate. The GR needs to
settle as much as it possibly can.
I think this is a good deal for the non-systemd community because
writing code, even to an interface that you didn't design and which
came from systemd, is a much more fun activity than political
fighting. It's also something we are all collectively much better at.
It is a good deal for the systemd community and the project as a whole
because it provides a clear and relatively uncontentious path to
progress.
Obviously for those who would prefer only to worry about systemd, it's
suboptimal. Those people should probably propose their own option (or
vote for Sam's). But I guess Thomas and Holger aren't in that camp
because they are both happy with the rest of my proposal, including
requiring "smooth transition for ... users ... of alternative init
systems".
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: