Re: [draft] Draft text on Init Systems GR
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>
> This is a draft GR. I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.
You can formally propose a GR today, and I recommend you do -- otherwise
we end up discussing things before the discussion period, and then you
need to sit and wait at least seven days during the *actual* discussion
period for no good reason.
Note that "proposing a GR" does not imply "calling for the vote"; that
happens later, after the GR has been properly drafted and discussion on
all amendments has ended.
Note also that every accepted amendment resets the discussion period,
and that while you have the ability (as DPL) to accept amendments
without seconds, and to vary the discussion period by up to a week, you
do not have the ability to eliminate the discussion period altogether.
Therefore it would make sense to have a formal GR proposal today so tha
amendments can be made.
> At this point, the question is whether the choices that need to be on
> the ballot are represented in this draft GR.
>
> I did not obtain a review of this version from someone who favors init
> diversity.
In my opinion, our GR procedure works best if every choice on the ballot
was drafted by someone who actually wants it to happen; otherwise you
run the risk of two problems:
- You may end up with options on the ballot that don't actually
represent the opinion of *any* developer, *at all*. This represents
clutter, and needlessly wastes time of voting developers who will have
to wade through reading a (number of) useless options that nobody
really wants.
- You will need to judge whether any proposed amendment matches the
opinion of anyone who previously already agreed with that option, when
you are not in the best position to do so. Every time you accept (or
reject) an amendment, you run the risk of alienating whoever actually
agreed with that proposal, possibly resulting in them proposing their
own alternate option.
This almost ended up happening for GR 2004_004, and that one was a mess.
Given your above statement, I'm assuming that your preferred option is
#3. Is that correct?
> I didn't give them a lot of time, and they just wrote to let
> me know that they weren't going to be able to do a review this week.
> Based on the feedback from debian-devel I decided that getting text to
> the community now was the most important thing.
> If this text doesn't meet the needs of that community, we'll change the
> text. I hope my actions demonstrate that I've tried to work with and
> understand the needs of all sides here; that has been my intent.
>
>
> ----------------------------------------
> version 2330c05afa4
>
> Using its power under Constitution section 4.1 (5), the project issues
> the following statement describing our current position on Init
> systems, Init system diversity, and the use of systemd features. This
> statement describes the position of the project at the time it is
> adopted. That position may evolve as time passes without the need to
> resort to future general resolutions. The GR process remains
> available if the project needs a decision and cannot come to a
> consensus.
>
> 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). Roughly, packages
> should include init scripts to start services that are included.
> Policy notes that early boot services like those started from
> /etc/rcS.d may be tied closely to the init system in use.
I don't see why this is relevant in the current discussion.
My nbd-client package is one that is relevant here; it has a systemd
unit, and an rcS init script (which is then ignored by systemd). If this
choice wins, then init scripts remain mandatory. If you provide an rcS
init script, then systemd units are also mandatory.
So this is not an exception to the rule? It just means you have more
work to do.
> Init
> scripts are the lowest common denominator across all init systems.
> Packages may include support for init systems like systemd service
> units in addition to init scripts. Current policy makes it an RC bug
> to include a service unit without an init script.
>
> 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.
If this choice wins, then why should it not be an RC bug to not have an
init script? That doesn't seem to make sense.
> Policy editors are requested to
> consider whether there are cases where removing an init script that
> used to be provided should be RC because it would break a system on
> upgrade.
>
> Once the community of users of an alternate init system have said that
> a solution is sufficiently functional for them, others should not
> generally second guess this determination.
I like this very much, thank you; there have been some people recently
who said things like "but the init script wouldn't provide functionality
XYZ, so it's not good enough", which is not a useful position to have
IMHO. Yes, if you choose to not use systemd, then certain functionality
won't be available, but that's fine; that's the choice you make.
> Choice 2: systemd but we Support Exploring Alternatives
[...]
As others have pointed out, this choice seems to be conflating two
separate issues, which is not generally helpful.
For that reason, I would recommend that you remove it from your draft
entirely. If someone feels strongly enough about it, they can propose
their own alternate option.
> Choice 3: systemd without Diversity as a Priority
[...]
No comments here.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: