Re: Replacing Proposal A

[Sam Hartman]

> "Sam" == Sam Hartman  writes:

Sam> Dear Secretary:

Sam> Based on discussion, I'd like to replace Proposal A with the
Sam> following amended text; I accept this amendment.

Sigh, and introduced a typo in the title:






Sam> Choice hartmans1: Init deversity is Important

How about Init Diversity is Important


Kurt, I think that titles are ultimately under your control.
I give any necessary permissions I might need to give for you to fix the
title.


signature.asc
Description: PGP signature

Replacing Proposal A

[Sam Hartman]

Dear Secretary:

Based on discussion, I'd like to replace Proposal A with the following
amended text; I accept this amendment.

I continue to adjust the discussion period to end November 30.

Based on Holger's recommendation I adjusted the title of the choice.
If you prefer the title you have now, I also accept that.




Choice hartmans1: Init deversity is Important

The project issues the following statement describing our current
position on Init systems, Init system diversity, and the use of
systemd facilities.  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.

Being able to run Debian systems with init systems other than systemd
continues to be something that the project values.  Every package
should work with pid1 != systemd, unless it was designed by upstream
to work exclusively with systemd and no support for running without
systemd is available.  It is a important bug (although not a serious
one) when packages should work without systemd but they do not.
According to the NMU guidelines, developers may perform non-maintainer
uploads to fix these bugs.

Software is not to be considered to be designed by upstream to work
exclusively with systemd merely because upstream does not provide,
and/or will not accept, an init script.


modification of Policy to adopt systemd facilities instead of
existing approaches is discouraged unless an equivalent implementation
of that facility is available for other init systems.
For my reference version a9a4121beb




Choice hartmans1: Init deversity is Important

The project issues the following statement describing our current
position on Init systems, Init system diversity, and the use of
systemd facilities.  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.

Being able to run Debian systems with init systems other than systemd
continues to be something that the project values.  Every package
should work with pid1 != systemd, unless it was designed by upstream
to work exclusively with systemd and no support for running without
systemd is available.  It is a important bug (although not a serious
one) when packages should work without systemd but they do not.
According to the NMU guidelines, developers may perform non-maintainer
uploads to fix these bugs.

Software is not to be considered to be designed by upstream to work
exclusively with systemd merely because upstream does not provide,
and/or will not accept, an init script.


modification of Policy to adopt systemd facilities instead of
existing approaches is discouraged unless an equivalent implementation
of that facility is available for other init systems.


signature.asc
Description: PGP signature

Re: Choice Hartmans1a

[Sam Hartman]

Hi.
You provided a diff to the text on the website, which hadn't been
updated with choice hartmans1A.

Attached is the patch I actually applied, which I believe is consistent
with the spirit of your changes.

diff --git a/init-system-gr b/init-system-gr
index dade7d0..f2ee7f2 100644
--- a/init-system-gr
+++ b/init-system-gr
@@ -2,7 +2,7 @@
 
 
 
-Choice hartmans1A: Init deversity is Important and NMUable
+Choice hartmans1A: Init deversity is Important
 
 The project issues the following statement describing our current
 position on Init systems, Init system diversity, and the use of
@@ -16,9 +16,10 @@ Being able to run Debian systems with init systems other 
than systemd
 continues to be something that the project values.  Every package
 should work with pid1 != systemd, unless it was designed by upstream
 to work exclusively with systemd and no support for running without
-systemd is available.  It is a important bug (although not a serious one) when
-packages should work without systemd but they do not.  Developers may
-perform non-maintainer uploads to fix these bugs.
+systemd is available.  It is a important bug (although not a serious
+one) when packages should work without systemd but they do not.
+According to the NMU guidelines, developers may perform non-maintainer
+uploads to fix these bugs.
 
 Software is not to be considered to be designed by upstream to work
 exclusively with systemd merely because upstream does not provide,

Re: Choice Hartmans1a

[Sam Hartman]

> "gregor" == gregor herrmann  writes:


gregor> Thanks for the clarification.

I am going to accept Holger's proposed changes and post this as an
accepted amendment to Proposal A.

>> I'd appreciate help in achieving these goals without undermining
>> the text in debref.

gregor> I think the main problem is actually that you try to write
gregor> down NMU rules in a GR; where they do not belong, as the NMU
gregor> guidelines develop in practice and are reflected in the
gregor> process of updating DevRef.

We're not in agreement on what belongs in a GR, especially in this GR.
I wonder if you believe that a GR sets long-running policy that would be
hard to overturn.

Yes, a GR can do that.
But This choice on this GR doesn't do that.

Quoting in part:

>The project issues the following statement describing our current
>position on Init systems, Init system diversity, and the use of
>systemd facilities.  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.

That is, this describes where we are today.
That can move along over time.

And yes, people can point back to the GR result and use that as a
justification.  For example if choice hartmans1A won the vote, and the
next day someone proposed we throw out sysvinit, it would be reasonable
to argue that it was exceedingly unlikely the project had changed its
mind in a day.  Even two years down the road, if someone proposed
throwing out sysvinit, you would presumably ask them to demonstrate a
consensus to do so or significant changed circumstances before seriously
considering the proposal.

But even a month later if the NMU guidelines had changed, arguing that
outdated text in the GR about NMUs no longer applied would be entirely
reasonable.
This GR is about  systemd and init systems, not NMU guidelines.
If it touches on NMU guidelines in an auxiliary manner, it's reasonable
to assume it does not stop the evolution of those guidelines.

Now, if choice hartmans1a passes, it would  be reasonable to discuss the
impact on the ability to fix init system related bugs in a discussion of
NMU guidelines.  I think that's fine and reasonable.
You wouldn't be obligated to keep things working the same, but someone
should argue you could, just as they could argue in favor of the status
quo in a number of ways.


Why do I wantto emphasize that you can NMU in choice hartmans1a?
Because one of the thing that various proponents of init diversity have
requested is the ability to do work without people blocking them.  Being
able to NMU gives a significant part of that, so I want to emphasize how
the option meets (or partially meets depending on your opinion) that
desire.

Re: Choice Hartmans1a

[gregor herrmann]

On Fri, 22 Nov 2019 08:01:37 -0500, Sam Hartman wrote:

> > "gregor" == gregor herrmann  writes:
> gregor> This contradicts the spirit, culture, and conventions around
> gregor> NMUs which are prevalent in Debian for at least ten years
> gregor> and are written down in DevRef 5.11.1.
> 
> I actually think that being able to NMU a package to add init system
> support is entirely consistent with what debref says about NMUs.
> It sounds like you're worried that I'm trying to lessen the categories
> of things that can be NMUed.
> Or that I'm tieing NMU to bug sevirity.
> I'm not trying to do that either.
> I'm trying to recommend a bug severity and emphasize that NMUs are
> appropriate.

Thanks for the clarification.
 
> I'd appreciate help in achieving these goals without undermining the
> text in debref.

I think the main problem is actually that you try to write down NMU
rules in a GR; where they do not belong, as the NMU guidelines
develop in practice and are reflected in the process of updating
DevRef.

From a different point of view: If you are just referring to the
existing NMU guidelines, why do you mention them in proposal 1a but
not in proposal 2 and 3?
 
> I think it is important to emphasize that these bugs can be NMUed in
> this choice.  

Why?
I mean, why are you treating these bugs differently than any other of
the gazillions of bugs, or more to the core of this GR, differently
from missing systemd service units in proposal 2 etc.?

> Since that is already consistent with the tradition you
> cite, I'm not seeing the problem.  

The problem in my opinion is mostly that this aspect doesn't belong
into this (or any) GR.

> But if you can suggest language that
> continues to emphasize that NMUs are appropriate in this situation
> without doing damage to that tradition, I would greatly appreciate it.

I think Holger's proposal goes in the right direction, although I
would go a step further and say, leave it out and maybe mention "BTW,
we have NMUs for bugs" in an appendix -- for all options.

> I do not support removing the statement about NMUs under the grounds
> that it is obvious.

Fine with me; personally I will rank all options talking about NMUs
below FD.

And taffit has captured my thoughts very good when he writes:


On Fri, 22 Nov 2019 06:06:59 -1000, David Prévot wrote:

> By doing that, this choice de facto overrides the currently documented
> (and working) NMU workflow and practices.
> I believe it opens a can of worms. It sets on stone an NMU workflow,
> making it impossible to let the rule evolve as it usually did. Worse, if
> such things is accepted via GR, one will be able to argue later that
> other NMU fixes are not acceptable (“the only NMU fix one can do is the
> one the project agreed on with GR2019#1“).

That's exactly what I oppose: Writing down NMU rules in a GR, even if
they at the time of writing just represent the current culture and
guidelines, will get into the way of adjusting them in the future.
 

Maybe this also answers a bit your followup question to taffit:

On Fri, 22 Nov 2019 12:40:47 -0500, Sam Hartman wrote:

> David> By doing that, this choice de facto overrides the currently
> David> documented (and working) NMU workflow and practices.
> In what way?
> How does it override them?
> To override them it needs to say something inconsistent with these
> practices.
> What is inconsistent between what the resolution says and the existing
> practices.

Currently probably nothing. But NMU guidelines might (want to) change
and then the GR is still there. And then they might contradict each
other. - I just don't see any advantage and potential disadvantages.


On a more general point (answering your other question on potentially
withdrawing your proposal 1(a)): Yes, I think as we have Ian's and
Dmitry's options I don't see any huge value in keeping hartmans1a on
the ballot.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: trio infernal: desafinado


signature.asc
Description: Digital Signature

Re: Re-Proposing: General Resolution on Init Systems and systemd

[Ansgar]

Sam Hartman writes:
> Choice hartmans3: Focus on systemd for Init System and Other Facilities
>
> 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 facilities.  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.
>
> The Debian project recognizes that systemd service units are the
> preferred configuration for describing how to start a daemon/service.
> Packages should include service units or init scripts to start daemons
> and services.  Unless the project or relevant parties have agreed
> otherwise, systemd facilities, where they exist and are stable and
> supported by the systemd maintainers, should be preferred over
> Debian-specific ways of solving the same problem unless the Debian
> approach has clear and obvious advantages.
>
>
> Providing support for multiple init systems or for alternatives to
> other interfaces provided by systemd is not a project priority at this
> time.
>
> Debian is committed to working with derivatives that make different
> choices about init systems.  As with all our interactions with
> downstreams, the relevant maintainers will work with the downstreams to
> figure out which changes it makes sense to fold into Debian and which
> changes remain purely in the derivative.
>
> Packages may include support for alternate init systems besides
> systemd.  Maintainers use their normal procedures for deciding which
> patches to include.

Seconded.

I think we should eventually move on from sysvinit-compatible init
scripts as mandatory lowest common denominator for all init systems and
so far this is the only proposal which seems to allow so.

Ansgar


signature.asc
Description: PGP signature

Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Russ Allbery]

Ansgar  writes:

> It's mostly that it pushes systemd preference a bit more than my
> preference, mostly because the short text also reads "Focus on systemd
> for [...] other facilities", but I have no preference for systemd over
> other implementations for "other facilities".

> I see value in cross-distribution collaboration which might be an
> advantage of solutions developed under the systemd umbrella, but that's
> not inherent so: it's the same for any other non-Debian specific
> implementation.

> Debian-specific solutions of course are also still fine if we believe
> these to be the best fit to our needs.

Yeah, this is all a good point.  I *think* it would work out the same in
practice, but there's definitely a good argument to be made for toning it
down a little to better reflect what I think the viewpoint is of systemd
proponents.  I think the median view of that perspective is closer to
yours (use the things that make sense taking into account
cross-distribution compatibility and other advantages) than to "prefer
systemd across the board."

-- 
Russ Allbery (r...@debian.org)  

Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Ansgar]

Russ Allbery writes:
> Ansgar  writes:
>> On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:
>
>>> Unless the project or relevant parties have agreed otherwise, systemd
>>> facilities, where they exist and are stable and supported by the
>>> systemd maintainers, should be preferred over Debian-specific ways of
>>> solving the same problem unless the Debian approach has clear and
>>> obvious advantages.
>
>> I don't think this is really what we might want: when there are multiple
>> competing options, Debian-specific or not, developed under the systemd
>> umbrella or not, which on Debian packagers decide to use should only be
>> on merit, i.e. there shouldn't be an implicit "we choose systemd by
>> default".
>
> This is the reason why I put "supported by the systemd maintainers" here,
> although that may not be sufficient to address your concern.  But the idea
> I had in mind was that the decision of whether to support the systemd
> facility would be an informed choice that takes into account concerns like
> that.

It's mostly that it pushes systemd preference a bit more than my
preference, mostly because the short text also reads "Focus on systemd
for [...] other facilities", but I have no preference for systemd over
other implementations for "other facilities".

I see value in cross-distribution collaboration which might be an
advantage of solutions developed under the systemd umbrella, but that's
not inherent so: it's the same for any other non-Debian specific
implementation.

Debian-specific solutions of course are also still fine if we believe
these to be the best fit to our needs.

Ansgar

Re: Choice Hartmans1a

[Sam Hartman]

> "David" == David Prévot  writes:

David> Le 22/11/2019 à 03:01, Sam Hartman a écrit :
>> I think it is important to emphasize that these bugs can be NMUed
>> in this choice.

David> By doing that, this choice de facto overrides the currently
David> documented (and working) NMU workflow and practices.

In what way?
How does it override them?
To override them it needs to say something inconsistent with these
practices.
What is inconsistent between what the resolution says and the existing
practices.

--Sam

Re: Choice Hartmans1a

[David Prévot]

Le 22/11/2019 à 03:01, Sam Hartman a écrit :

> I think it is important to emphasize that these bugs can be NMUed in
> this choice.

By doing that, this choice de facto overrides the currently documented
(and working) NMU workflow and practices.

I believe it opens a can of worms. It sets on stone an NMU workflow,
making it impossible to let the rule evolve as it usually did. Worse, if
such things is accepted via GR, one will be able to argue later that
other NMU fixes are not acceptable (“the only NMU fix one can do is the
one the project agreed on with GR2019#1“).

There were other concerns raised about RCness and severity of bugs.
Given the length of many of the proposed options, I wonder how many of
those counterproductive corner cases will we be able to find in the next
twenty years.

In the past, at least GR2007#2 (the only GR I was able to find that
evokes NMU) was worded as “the initial policy [on matter X is …]”,
making it possible to let things evolve without the need to endure
another GR process.

GR2007#2: https://www.debian.org/vote/2007/vote_003

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Init Diversity

[Kurt Roeckx]

On Thu, Nov 21, 2019 at 01:44:09PM -0500, Brian Gupta wrote:
> On Thu, Nov 21, 2019 at 1:33 PM Kurt Roeckx  wrote:
> 
> > On Thu, Nov 21, 2019 at 12:49:47PM -0500, Brian Gupta wrote:
> > > On Thu, Nov 21, 2019 at 9:02 AM Kurt Roeckx  wrote:
> > >
> > > > On Wed, Nov 20, 2019 at 11:10:13PM -0500, Brian Gupta wrote:
> > > > >
> > > > > Please consider the above version, and all future variants that
> > contain
> > > > > nothing
> > > > > but grammar/wording changes, seconded by me. (As opposed to meaning
> > > > > changes.)
> > > >
> > > > I was unable to verify your signature.
> > > >
> > >
> > > Trying again. If this doesn't work, I'll send as an attachment. (I didn't
> > > change my text, even though there have been some changes to the wording
> > of
> > > the ammendment.)
> >
> > I still get:
> > *BAD* signature from: Brian Gupta 
> >  aka: Brian Gupta 
> >  aka: Brian Gupta 
> >
> >
> > Kurt
> >
> 
> Alright, thanks. Please try the attached. If it's still not working I'll
> have to take some time to debug.

That was good.


Kurt

Re: [draft] Draft text on Init Systems GR

[Thomas Goirand]

On 11/19/19 7:29 PM, Ian Jackson wrote:
> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson  writes:
>>> Please do formally propose it and I will give my formal blessing to it.
> 
>> If I understand the process correctly, that looks like this:
> 
>> I propose that point 7 of Iam's seconded proposal be replaced with point 7
>> as shown here:
> 
> I accept this amendment.  The amended version should replace my
> proposal.  For completeness, I enclose it.  (My ref e8942d8c.)
> 
> Thanks,
> Ian.
> 
> -8<-
> 
> Title: Support non-systemd systems, without blocking progress
> 
> PRINCIPLES
> 
> 1. We wish to continue to support multiple init systems for the
>foreseeable future.  And we want to improve our systemd support.
>We are disappointed that this has had to involve another GR.
> 
> 2. It is primarily for the communities in each software ecosystem to
>maintain and develop their respective software - but with the
>active support of other maintainers and gatekeepers where needed.
> 
> SYSTEMD DEPENDENCIES
> 
> 3. Ideally, packages should should be fully functional with all init
>systems.  This means (for example) that daemons should ship
>traditional init scripts, or use other mechanisms to ensure that
>they are started without systemd.  It also means that desktop
>software should be installable, and ideally fully functional,
>without systemd.
> 
> 4. So failing to support non-systemd systems, where no such support is
>available, is a bug.  But it is *not* a release-critical bug.
>Whether the requirement for systemd is recorded as a formal bug in
>the Debian bug system, when no patches are available, is up to the
>maintainer.
> 
> 5. When a package has reduced functionality without systemd, this
>should not generally be documented as a (direct or indirect)
>Depends or Recommends on systemd-sysv.  This is because with such
>dependencies, installing such a package can attempt to switch the
>init system, which is not the what the user wanted.  For example, a
>daemon with only a systemd unit file script should still be
>installable on a non-systemd system, since it could be started
>manually.
> 
>One consequence of this is that on non-systemd systems it may be
>possible to install software which will not work, or not work
>properly, because of an undeclared dependency on systemd.  This is
>unfortunate but trying to switch the user's init system is worse.
>We hope that better technical approaches can be developed to
>address this.
> 
> 6. We recognise that some maintainers find init scripts a burden and
>we hope that the community is able to find ways to make it easier
>to add support for non-default init systems.  Discussions about the
>design of such systems should be friendly and cooperative, and if
>suitable arrangements are developed they should be supported in the
>usual ways within Debian.
> 
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
> 
> 7. Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bug.  For example: init
>scripts *must not* be deleted merely because a systemd unit is
>provided instead; patches which contribute support for other init
>systems (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'.
> 
>This is intended to provide a lightweight but effective path to
>ensuring that reasonable support can be provided to Debian users,
>even where the maintainer's priorities lie elsewhere.  (Invoking
>the Technical Committee about individual patches is not sensible.)
> 
>If the patches are themselves RC-buggy (in the opinion of,
>initially, the maintainer, and ultimately the Release Team) then of
>course the bug report should be downgraded or closed.
> 
> 8. Maintainers of systemd components, or other gatekeepers (including
>other maintainers and the release team) sometimes have to evaluate
>technical contributions intended to support non-systemd users.  The
>acceptability to users of non-default init systems, of quality
>risks of such contributions, is a matter for the maintainers of
>non-default init systems and the surrounding community.  But such
>contributions should not impose nontrivial risks on users of the
>default configuration (systemd with Recommends installed).
> 
> NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES
> 
> 9. systemd provides a variety of facilities besides daemon startup.
>For example, creating system users or temporary directories.
>Current Debian approaches are often based on debhelper scripts.
> 
>In general more declarative approaches are better.  Where
>  - systemd provides such facility
>  - a specification of the facility (or suitable subset) exists

Re: Choice Hartmans1a

[Holger Levsen]

On Fri, Nov 22, 2019 at 08:01:37AM -0500, Sam Hartman wrote:
> I'd appreciate help in achieving these goals without undermining the
> text in debref.
 
Choice 1: Init deversity is Important and NMUable
->
Choice 1: Init diversity is Important

and

However, adding an init script to such a package is appropriate for a
non-maintainer upload. 
->
This also means, that according to the NMU guidelines, adding an init
script to such a package is appropriate for a non-maintainer upload. 

...and non-maintainer uploads to add that support are appropriate. 
->
...and non-maintainer uploads following the NMU guidelines to add that
support are appropriate.

on the text on 

https://www.debian.org/vote/2019/vote_002#proposera with Last Modified: 
Thu, Nov 21 17:08:51 UTC 2019   Last Built: Thu, Nov 2117:09:59 UTC 2019 


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Choice Hartmans1a

[Sam Hartman]

> "gregor" == gregor herrmann  writes:

gregor> On Thu, 21 Nov 2019 13:58:09 -0500, Sam Hartman wrote:
>> Choice hartmans1A: Init deversity is Important and NMUable
gregor> […]
>> Developers may perform non-maintainer uploads to fix these bugs.

gregor> This contradicts the spirit, culture, and conventions around
gregor> NMUs which are prevalent in Debian for at least ten years
gregor> and are written down in DevRef 5.11.1.


I actually think that being able to NMU a package to add init system
support is entirely consistent with what debref says about NMUs.
It sounds like you're worried that I'm trying to lessen the categories
of things that can be NMUed.
Or that I'm tieing NMU to bug sevirity.
I'm not trying to do that either.
I'm trying to recommend a bug severity and emphasize that NMUs are
appropriate.

I'd appreciate help in achieving these goals without undermining the
text in debref.

The text does not currently tie the ability to NMU to bug severity.
Important bugs are valuable for among other reasons being suitable for
inclusion in a stable release update.

I think it is important to emphasize that these bugs can be NMUed in
this choice.  Since that is already consistent with the tradition you
cite, I'm not seeing the problem.  But if you can suggest language that
continues to emphasize that NMUs are appropriate in this situation
without doing damage to that tradition, I would greatly appreciate it.
I do not support removing the statement about NMUs under the grounds
that it is obvious.

Re: Should I withdraw choice hartmans1?

[Holger Levsen]

On Fri, Nov 22, 2019 at 01:32:35AM +, Dmitry Bogatov wrote:
> [ I read version of hartman1, which is based on my draft with s/must/should/]
> 
> I do not think your option actually adds value, and not aware of
> somebody, who prefers your option to either Ian's or mine.  On other
> hand our system is resistant to multiple close options, so the only loss
> is that every voter will have to thorously read one more text.

I disagree and very much think that it's useful to have hartman1 as an
option. 'should' or 'must' makes a whole lot of difference.

(I do however also agree with gregoa's comments on the NMU part of this:
'Inventing NMUability rules tied to bug severities in a GR seems
counterproductive to me.' and 'This contradicts the spirit, culture, and
conventions around NMUs which are prevalent in Debian for at least ten years
and are written down in DevRef 5.11.1.'.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature