Re: Proposal: General Resolution on Init Systems and systemd Facilities
Sam Hartman writes ("Re: Proposal: General Resolution on Init Systems and systemd Facilities"):
> Under Russ's option B and C, which I capture in my proposal, non-systemd
> users get degraded behavior until we agree on an approach and
> standardize it.
The reason this is unacceptable to me is because it makes things
continuing to work on non-systemd systems dependent on policy
consensus, and therefore on the agreement of systemd advocates.
All my proposal does is temporarily delay the adoption of useful new
features, to give a reasonable time for consideration (with a clear
escalation path) and implementation. No systemd advocates will find
their useful work indefinitely blocked.
> And the disagreement is whether the answer is a presumed yes you can use
> the facility or you need to go through the process ahead of time.
> I believe that my options accurately reflect the discussion I was trying
> to capture.
>
> The up-side of that is that it makes it easy to use new facilities.
> The down sides are the ones you've pointed out.
The problem with even your option B is that there is no effective
route for non-systemd systems to "catch up" as you put it.
> I think that you could find a few people who want to support both
> systemd timers and cron jobs together.
> And once you found a good way to do that, you could get it into policy.
Getting it into policy is going to be very difficult. People who only
want to do systemd will see that they can get what they want ("just
use all the systemd features and don't have to worry about anything
else") by blocking policy change.
Even when a shared approach is agreed in policy, there will be nothing
stopping maintainers from, for example, using new systemd subfeatures
of questionable value, and breaking things again.
Sometimes the interface agreed in policy will have to be not "just the
systemd thing" (eg with timer units) and then maintainers will be able
to block support by just stalling on patches. For example, patches to
do some kind of conditional cron vs timer unit thing will probably be
thought ugly and not accepted.
So I am saying that your option B is setting us up for more years of
fighting. I don't want more years of fighting. I want us to do
programming instead.
> Your proposal blocks people from using the new facility until that
> discussion happens.
My proposal provides a clear escalation path, and clear guidance to
the TC. No useful new facilities will be blocked forever.
It is true that adoption of new facilities does in my proposal depend
on some discussion. But indeed that is reasonable. There aren't (or
shouldn't be) other fields of our distro where adoption of new
features which require new work by a significant number of people, can
be done without any kind of discussion.
Russ, Sam has mentioned your name. Are you happy with the situation
that is being set up with option B ?
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: