Re: [draft] Draft text on Init Systems GR
This is a reply to multiple messages.
I know it's long, I don't see a way to avoid that.
Search for lines of equal signs (=) to split issues I'm replying to.
Working with Downstreams
========================
So, a couple of people have commented on the commitment to work with
downstreams in choice 2 and 3.
Here's what that commitment means to me.
It means that we'll work with derivatives to figure out where the
boundary is between their derivative and Debian. We (particularly the
DPL) will be responsive to questions about where that boundary is. When
it is not obvious, that may involve discussion on -project or -devel.
Let's take choice 3 as an example.
* Devuan reports a bug in dpkg independent of init systems that they can
reproduce on Debian. We're happy to take their bug report.
* They don't get a response in the time frame they are hoping for. They
write to the DPL. (the DPL does sometimes get messages from people
outside the community hoping for help in getting things to move
faster). The DPL looks at the issue and decides how much of their time
they want to invest. Perhaps the DPL writes a polite note explaining
that Debian developers are all volunteers. Perhaps the DPL prods the
dpkg maintainer and asks if there's any way it can move faster. Perhaps
the DPL gives a suggestion on how Devuan can make the bug report more
useful (better test case, comments about a patch). Perhaps the DPL
solicits someone in the Debian community to do the above.
* Devuan wonders whether it still makes sense for them to submit patches
to packages including init scripts under choice 3. We have a discussion
on -devel and if there is a consensus let them know what it is.
* A derivative writes to us asking if we'd consider a patch to make
things easier in some way when not running systemd. We review the patch
just as we would (and just as [in]efficiently) other patch submissions
we get.
Under choice 2:
One of the reasons that I started looking into this was requests I got
from people inside Devuan about challenges with elogind in Debian. It
turns out I got the same request with people involved in maintaining
elogind inside Debian too, and I focused on that side of the request
more than the Devuan request. I didn't understand the project consensus
on how much we value elogind enough to understand what I should do.
Some of the feedback I got from within Debian was that sysvinit was dead
and people were not reviewing patches/engaging with elogind issues
because they hoped it would go away.
If the project supports choice 3, that's a fine response. If we support
choice 1 or choice 2, that's not a great response from someone who is in
a gatekeeper role.
In my mind commitment to work with downstreams is far more about letting
them know how they can interact with Debian and what they can expect.
It is not a promise to do any particular thing, more a commitment to
keep communication lines open.
Choice 1 Policy Language
========================
>>>>> "Ansgar" == Ansgar <ansgar@43-1.org> writes:
>> Choice 1: Affirm Init Diversity
>>
>> Being able to run Debian systems with init systems other than
>> systemd continues to be something that the project values. With
>> one exception, the Debian Project affirms the current policy on
>> init scripts and starting daemons (policy 9.3.2, 9.11).
Ansgar> I would not recommend referring to the "current policy" as
Ansgar> it is unclear
Ansgar> what that is.
I understand your concern.
I'd be delighted to work with proponents of init system diversity to
reword choice 1 without referring to current policy language if that's
something they want to do.
And certainly anyone can propose an amendment to that effect.
My rationale for choice 1 as it stands today is that I've gotten
significant feedback from some people that they want a status quo option
in terms of the current policy. I did have enough discussions with Russ
that I think the summary in choice 1 of what current policy means is
fairly accurate. If we get the right people engaged in a discussion of
rewording choice 1, I think it would be great.
>>>>> "Holger" == Holger Levsen <holger@layer-acht.org> writes:
Constitutional Basis
====================
Holger> I fail to see why Constitution section 4.1 (5) is referred
Holger> here. I'd better understand section 4.1 (4) and would
Holger> probably would prefer to leave out this half sentence
Holger> completly.
The secretary has expressed a preference for making it clear what
constitutional power is used when proposing a resolution. That was in
a TC context, but I think applies equally here.
I prefer 4.1(5) to 4.1 (4) for a couple of reasons. TFor those who
don't have the constitution memorized we're debating whether to make a
statement of the day (4.1 (5)) or to make a decision under TC power (4.1
(4)). A statement of the day is less forceful; it doesn't have any
formal power. It lets us understand consensus, but allows maintainers
and policy editors to interpret what we say. If it turns out we missed
some key issue in our discussion, they can even come back to
debian-devel and raise the issue. If we used TC power, we'd need to
decide which TC power to use. Presumably you'd be thinking of 6.1.1
(setting technical policy). I guess you could be talking about 6.1 (5:
offering advice), but that's so close to a statement of the day that it
doesn't make sense to me.
Setting policy requires us to get a lot more precise and to get the
details right in a way that seems hard for a GR.
Also, using power under 4.1 (4) requires a 2:1 majority, where as simply
making a statement of the day is a simple majority.
I think that if we know the views of the project, the rest will fall
into place in policy and in other areas.
So I prefer to use the smallest hammer that will accomplish that goal.
Choice 1: RC or Not
===================
>>>>> "Wouter" == Wouter Verhelst <wouter@debian.org> writes:
>> Policy editors are requested to amend policy; including a service
>> unit without an init script is appropriate for a non-maintainer
>> upload but should no longer be an RC bug.
Wouter> If this choice wins, then why should it not be an RC bug to
Wouter> not have an init script? That doesn't seem to make sense.
In current policy, it's a normal bug to not include an automated way of
starting a daemon at all.
So, no init script, no systemd unit is a normal bug.
But if you provide a systemd unit without a init script, that is an RC
bug.
While I did not get review of the final text from my init diversity
reviewer, I did discuss this particular point with a number of people
who favor init diversity.
Overwhelmingly they were asking for the ability to be able to work on
init diversity.
They weren't talking about blocking other people's work or about
stopping people from using systemd. They just wanted their patches
reviewed in a timely manner, wanted to be able to decide what was good
enough for sysvinit users, and wanted patches that met that bar (and
didn't introduce other problems) to be accepted.
The current policy is very much perceived as the init diversity crowd
trying to hold the RC hammer over others.
Multiple people were either surprised that policy reads as it does
today, or that the policy editors couldn't get consensus to make this
change on their own.
I was prepared to have two versions of choice 1: one with no init script
RC, and the current version. But at least in the people I talked to, I
wasn't seeing a strong enough desire for the init script RC option.
Holger> On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>> ---------------------------------------- version 2330c05afa4
>> Choice 3: systemd without Diversity as a Priority
Holger> [...]
Choice 3 Title
==============
Holger> a.) 'systemd without diversity as a priority' sounds like
Holger> systemd is against diversity. I think this is borderline
Holger> insulting. So I expect this will attract someone proposing
Holger> another option called 'Embrace the future (*) and a modern
Holger> init system' or such. *) or 'Embrace new technologies...'
The systemd maintainers I ran the text by didn't complain about the
title. Please speak up if you find the current title insulting toward
systemd. I'm taking holger's current wording as a potential concern,
not as something that he specifically finds insulting himself.
Systemd Features Beyond Init
============================
Holger> On top of all of this, systemd provides much more features
Holger> than unit files as the thread on -devel showed. There is no
Holger> word about these technologies in this GR proposal. I think
Holger> that's a flaw in this proposal.
This proposal actually does speak to that issue.
Obviously, the policy process may adopt limits on systemd technologies
we use, and nothing in this proposal stops people from working to form a
consensus on such a limit.
But absent limits in policy, maintainers can generally use any systemd
feature they like that the systemd maintainers enable in our builds.
The question is wether maintainers need to provide non-systemd
alternatives when they use such a feature.
This proposal does speak to that choice.
Choice 2 and 3 say that individual maintainers may include alternatives
for individual systemd features if they choose.
That may is intended to be my permissive: my reading of choice 2 and 3
is that it is not a bug to use a systemd feature without an alternative.
Reply to: