Re: Question Under Proposal D: Compile Time Option

[Thibaut Paumard]

Le 29/11/2019 à 23:32, Sam Hartman a écrit :
> 
> Ian, I find  that I'm not able to answer Simon's question with regard to
> Proposal D.
> 
> Imagine that we have a program that has compile time support for systemd
> and for other mechanisms.  It provides enhanced functionality when built
> against systemd, but when so built, it cannot run without systemd.
> 
> It's packaged that way in Debian.
> Someone files a bug with a patch that changes the compilation option to
> support the non-systemd bug, removing the enhanced systemd
> functionality.
> 
> What does proposal D say about this?
> Is the package RC buggy under proposal D until this patch is applied?
> Does the maintainer have the option to retain the enhanced
> functionality?
> 


Dear Sam,


I think the right fix would be to compile the package twice as "foo"
(for the systemd version) and "foo-non-systemd".

Another option would be to ship both versions in package "foo" and
decide at runtime which one to run, if technically feasible.

My understanding of D.7 is that, If someone provides a patch that
implements either of this in a maintainable fashion, this patch should
be accepted.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Re: Review of proposals

[Russ Allbery]

Lucas Nussbaum  writes:

> I think that clause 9 could be significantly reduced, to something such
> as the following, which still captures the main ideas of the current
> clause. But we clearly disagree on how much details should go into the
> GR, and I don't see us agreeing anytime soon :)

>   9. systemd provides a variety of facilities besides daemon startup.
>   For example, creating system users or temporary directories. When
>   those are better than the current Debian approaches, transitions
>   should be carried out while ensuring that it is possible for the
>   non-systemd community to implement support for the new facility in
>   non-systemd systems, in order to ensure a smooth transition for all
>   users. This includes, for example, proper documentation of the
>   specification of the new facility, and a transition plan that allows
>   enough time to work on alternative implementations of the facility.

Speaking as one of the Policy editors, personally I'd rather have the
explicit time frame so that we don't have to argue about what "enough
time" means.  I like Ian's explicit list, which preempts a lot of the
expected arguments.

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

Re: Review of proposals

[Lucas Nussbaum]

Hi,

Note that I'm not in the best position to propose changes, because I
am unlikely to vote it very high in any case.

On 29/11/19 at 11:44 +, Ian Jackson wrote:
> > 2/ It says:
> > > If policy consensus cannot be reached on such a facility, the
> > > Technical Committee should decide based on the project's wishes
> > > as expressed in this GR.
> > 
> > Well, given that some of the criterias are not super-clear (see above),
> > it's likely that policy consensus will be hard to reach. Then the TC is
> > left with deciding based on the project's wishes as expressed in this
> > GR. But assuming that proposal D wins, where is that project's wish on
> > non-init-related declarative systemd facilities expressed?
> 
> That is referring to the list of criteria in my clause 9
> (contextualised bn with the rest of of the whole proposal including
> (for example) the principles in clauses 1 and 2).
> 
> What this is saying is that if we can't get policy consensus on
> whether the clause 9 criteria are met, the TC should decide the same
> question.
> 
> I'm sorry that this isn't clear to you.  I'd be happy to improve that.

To clarify this, it might help to drop "based on the project's wishes as
expressed in this GR." I think that asking the TC to decide based on
specific elements is going to add noise to the discussions.

> > I'm also not sure about the part about "being excellent to each other".
> > How does this part of this GR interact with the CoC? Is it expected that
> > the CoC includes special cases about init systems if this proposal wins?
> 
> I think your criticism here is addressed primarily at my clause 11.
> 
> Directly in answer to your question, no.  If I wanted to modify the
> CoC I would say so explicitly.  The CoC is quite generic, whereas this
> GR is quite specific.  I don't know if you have been hanging around on
> -devel and reading the discussions there ?  Clause 11 is trying to
> address some of the specific pathologies we see in those discussions.
> 
> Do you see the same pathologies ?  If so, what do you think should be
> done to try to address them ?  The existing CoC etc. do not seem to be
> effective.

I think that it is more a problem with how we are enforcing the CoC
(because this is hard, not because we are doing a particularly bad job).
I don't think that the part about "being excellent to each other" is
going to help.

> > For those reasons, I am not sure if I will rank proposal D above FD. I
> > would very much prefer if it were compressed to a proposal of about the
> > same length as proposals B or C.
> 
> I am sorry it is so long, indeed.  It's just that I don't see what to
> cut.  The init systems wars have been so wide-ranging and demonstrated
> a large variety of different pathologies, and poor arguments, as well
> as of course high-level differences of approach.

I think that clause 9 could be significantly reduced, to something such
as the following, which still captures the main ideas of the current
clause. But we clearly disagree on how much details should go into the
GR, and I don't see us agreeing anytime soon :)

  9. systemd provides a variety of facilities besides daemon startup.
  For example, creating system users or temporary directories. When
  those are better than the current Debian approaches, transitions
  should be carried out while ensuring that it is possible for the
  non-systemd community to implement support for the new facility in
  non-systemd systems, in order to ensure a smooth transition for all
  users. This includes, for example, proper documentation of the
  specification of the new facility, and a transition plan that allows
  enough time to work on alternative implementations of the facility.

Lucas

Re: Proposal: Focus on systemd

[Sam Hartman]

> "gregor" == gregor herrmann  writes:

gregor> On Fri, 29 Nov 2019 18:12:48 -0500, Sam Hartman wrote:
>> I'm trying to figure out if the new proposal is redundant with
>> proposal C.  The text is obviously very different, but I'm trying
>> to figure out if there are any practical differences.  Understand
>> this is not a criticism of this proposal, but if there are no
>> significant practical differences I am enclined to withdraw
>> Proposal C.

gregor> Without having thought this through, I have a gut feeling
gregor> that you could withdraw all of your original proposals,
gregor> because we now have 3 clear proposals, worded by the
gregor> respective proponents, for the 3 general directions:
gregor> Dmitry's pro multiple init systems variant, Ian's compromise
gregor> proposal, and now tbm's clear pro systemd text.

Proposal B is not a compromise proposal in the same direction as Ian's.

Proposal B is a lot closer to proposal C/F than  anything Ian would
support.
Proposal B is targeted at a different kind of compromise.
One that I heard under the subtext of people I was talking to who were
not involved enough that they were going to write their own text.
People who are skeptical of  systemd, but who believe it is superior to
the other existing init systems.


The big difference between proposal B and F/C is that proposal B
obligates gatekeepers like the release team to think about the issues
involved in integrating technologies that might provide alternatives to
systemd.  It says that as a project we'll work with people to run
experiments at a global level, but does not commit individual
maintainers to support these experiments.
Under proposals C/F, the project level gatekeepers probably wouldn't
cooperate with such experiments.

Under all three systemd options (B/C/F), individual packages are not
obligated to support alternate init systems.

Re: Proposal: Focus on systemd

[Sean Whitton]

Hello Martin, and seconders of proposal F,

On Fri 29 Nov 2019 at 10:16PM +02, Martin Michlmayr wrote:

> I'd like submit the following proposal:
>
> Proposal: Focus on systemd to promote standardization and
> cross-distribution cooperation

I would be grateful for an informal summary of why proposal F is thought
to be needed on the ballot in addition to proposal C.  What is thought
not captured well by Sam's text, but is thought to be captured well by
Martin's text?

I don't mean to challenge the idea that proposal F is needed in addition
to proposal C.  I am just hoping to better understand the motivations
behind proposal F than what I've been able to glean by putting the texts
of proposals C and F side-by-side.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[gregor herrmann]

On Fri, 29 Nov 2019 18:12:48 -0500, Sam Hartman wrote:

> I'm trying to figure out if the new proposal is redundant with proposal
> C.  The text is obviously very different, but I'm trying to figure out
> if there are any practical differences.  Understand this is not a
> criticism of this proposal, but if there are no significant practical
> differences I am enclined to withdraw Proposal C.

Without having thought this through, I have a gut feeling that you
could withdraw all of your original proposals, because we now have 3
clear proposals, worded by the respective proponents, for the 3
general directions: Dmitry's pro multiple init systems variant, Ian's
compromise proposal, and now tbm's clear pro systemd text.
 

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: Beatles


signature.asc
Description: Digital Signature

Re: Proposal: Focus on systemd

[Holger Levsen]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.

seconded & thanks.

And I'd also like to say that I'd like Debian to stay the harbour for us
all. Debian can be bend & expanded in many ways, especially technically.


-- 
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: Proposal: Focus on systemd

[Philipp Kern]

On 11/29/2019 9:16 PM, Martin Michlmayr wrote:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.

Seconded. Thank you for putting this onto the ballot.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Focus on systemd

[Sam Hartman]

Hi.

I'm trying to figure out if the new proposal is redundant with proposal
C.  The text is obviously very different, but I'm trying to figure out
if there are any practical differences.  Understand this is not a
criticism of this proposal, but if there are no significant practical
differences I am enclined to withdraw Proposal C.

Differences I notice:

* The preamble is shorter.  I think it has the same effect though.  If
  the intente of Proposal F is to limit our ability to change things if
  we reach a consensus more than proposal C, I'd like to see this more
  explicitly spelled out.  However, my current assumption is that as a
  statement under 4.1(5) it would be reasonable for project consensus
  should it diverge from this GR to guide the project without repealing
  the GR.

* The text about working with downstreams is different.
Unless explicitly directed otherwise by the project I at least plan to
continue to work with downstreams and help them figure out where their
efforts can be contributed and where they cannot.
So, I don't see this as a change.

* The language about using systemd facilities is even stronger than that
  in proposal C.

Are there any other changes that actually effect what maintainers could
or could not do between proposal C and F?

Re: Proposal: Focus on systemd

[Jordi Mallach]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

Seconded.

-- 
Jordi Mallach 


signature.asc
Description: PGP signature

Question Under Proposal D: Compile Time Option

[Sam Hartman]

Ian, I find  that I'm not able to answer Simon's question with regard to
Proposal D.

Imagine that we have a program that has compile time support for systemd
and for other mechanisms.  It provides enhanced functionality when built
against systemd, but when so built, it cannot run without systemd.

It's packaged that way in Debian.
Someone files a bug with a patch that changes the compilation option to
support the non-systemd bug, removing the enhanced systemd
functionality.

What does proposal D say about this?
Is the package RC buggy under proposal D until this patch is applied?
Does the maintainer have the option to retain the enhanced
functionality?

Re: Proposal: Focus on systemd

[Kurt Roeckx]

On Fri, Nov 29, 2019 at 09:17:58PM +, Luca Filipozzi wrote:
> On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> > Proposal: Focus on systemd to promote standardization and
> > cross-distribution cooperation
> 
> Seconded.

The message was nog signed.


Kurt

Re: Proposal: Focus on systemd

[Luca Filipozzi]

On Fri, Nov 29, 2019 at 09:17:58PM +, Luca Filipozzi wrote:
> On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> > Proposal: Focus on systemd to promote standardization and
> > cross-distribution cooperation
> 
> Seconded.

Let me sign this before Kurt responds.

-- 
Luca Filipozzi


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Kurt Roeckx]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

So I counted enough seconds and it's on the website now.


Kurt

Re: Proposal: Focus on systemd

[intrigeri]

> I'd like submit the following proposal:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

Seconded.

-- 
intrigeri


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Luca Filipozzi]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> Proposal: Focus on systemd to promote standardization and
> cross-distribution cooperation

Seconded.

-- 
Luca Filipozzi

Re: Proposal: Focus on systemd

[Kurt Roeckx]

On Fri, Nov 29, 2019 at 04:01:38PM -0500, Paul R. Tagliamonte wrote:
> Seconded

That wasn't signed.


Kurt

Re: Proposal: Focus on systemd

[Russ Allbery]

I second the below amendment.

Martin Michlmayr  writes:

> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:

> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.

> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.

> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.

> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.

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


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Ana Guerrero Lopez]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.

Seconded, thanks.

Ana



signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Paul R. Tagliamonte]

Seconded

On Fri, Nov 29, 2019, 3:54 PM Julien Cristau  wrote:

> On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> > Proposal: Focus on systemd to promote standardization and
> cross-distribution cooperation
> >
> > This resolution is a position statement under section 4.1 (5) of the
> > Debian constitution:
> >
> > Cross-distribution standards and cooperation are important factors in
> > the choice of core Debian technologies.  It is important to recognize
> > that the Linux ecosystem has widely adopted systemd and that the level
> > of integration of systemd technologies in Linux systems will increase
> > with time.
> >
> > Debian is proud to support and integrate many different technologies.
> > With everything we do, the costs and benefits need to be considered,
> > both for users and in terms of the effects on our development community.
> > An init system is not an isolated component, but is deeply integrated in
> > the core layer of the system and affects many packages.  We believe that
> > the benefits of supporting multiple init systems do not outweigh the
> > costs.
> >
> > Debian can continue to provide and explore other init systems, but
> > systemd is the only officially supported init system.  Wishlist bug
> > reports with patches can be submitted, which package maintainers should
> > review like other bug reports with patches.  As with systemd, work
> > should be done upstream and in cooperation with other Linux and FOSS
> > distributions where possible.  The priority is on standardization
> > without the reliance on complicated compatibility layers.
> >
> > Integrating systemd more deeply into Debian will lead to a more
> > integrated and tested system, improve standardization of Linux systems,
> > and bring many new technologies to our users.  Packages can rely upon,
> > and are encouraged to make full use of, functionality provided by
> > systemd.  Solutions based on systemd technologies will allow for more
> > cross-distribution cooperation.  The project will work on proposals and
> > coordinate transitions from Debian-specific solutions where appropriate.
> >
> Seconded.
>
> Cheers,
> Julien
>

Re: Proposal: Focus on systemd

[Matthias Klumpp]

Am 29.11.19 um 21:16 schrieb Martin Michlmayr:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.
> 
> ---
> 
> Thanks to Enrico Zini, Michael Biebl and others for help with
> drafting this proposal.
> 

Thank you for putting this together!
Seconded by me as well.



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Focus on systemd

[Enrico Zini]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:

> I'd like submit the following proposal:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

Seconded.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Ansgar]

Martin Michlmayr writes:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
>
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
>
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
>
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
>
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
>
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.

Seconded.

Ansgar


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Julien Cristau]

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.
> 
Seconded.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Michael Biebl]

Am 29.11.19 um 21:16 schrieb Martin Michlmayr:
> I'd like submit the following proposal:
> 
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation
> 
> This resolution is a position statement under section 4.1 (5) of the
> Debian constitution:
> 
> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.
> 
> Debian is proud to support and integrate many different technologies.
> With everything we do, the costs and benefits need to be considered,
> both for users and in terms of the effects on our development community.
> An init system is not an isolated component, but is deeply integrated in
> the core layer of the system and affects many packages.  We believe that
> the benefits of supporting multiple init systems do not outweigh the
> costs.
> 
> Debian can continue to provide and explore other init systems, but
> systemd is the only officially supported init system.  Wishlist bug
> reports with patches can be submitted, which package maintainers should
> review like other bug reports with patches.  As with systemd, work
> should be done upstream and in cooperation with other Linux and FOSS
> distributions where possible.  The priority is on standardization
> without the reliance on complicated compatibility layers.
> 
> Integrating systemd more deeply into Debian will lead to a more
> integrated and tested system, improve standardization of Linux systems,
> and bring many new technologies to our users.  Packages can rely upon,
> and are encouraged to make full use of, functionality provided by
> systemd.  Solutions based on systemd technologies will allow for more
> cross-distribution cooperation.  The project will work on proposals and
> coordinate transitions from Debian-specific solutions where appropriate.
> 

Thank you Martin.

Seconded.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Proposal: Focus on systemd

[Martin Michlmayr]

I'd like submit the following proposal:

Proposal: Focus on systemd to promote standardization and cross-distribution 
cooperation

This resolution is a position statement under section 4.1 (5) of the
Debian constitution:

Cross-distribution standards and cooperation are important factors in
the choice of core Debian technologies.  It is important to recognize
that the Linux ecosystem has widely adopted systemd and that the level
of integration of systemd technologies in Linux systems will increase
with time.

Debian is proud to support and integrate many different technologies.
With everything we do, the costs and benefits need to be considered,
both for users and in terms of the effects on our development community.
An init system is not an isolated component, but is deeply integrated in
the core layer of the system and affects many packages.  We believe that
the benefits of supporting multiple init systems do not outweigh the
costs.

Debian can continue to provide and explore other init systems, but
systemd is the only officially supported init system.  Wishlist bug
reports with patches can be submitted, which package maintainers should
review like other bug reports with patches.  As with systemd, work
should be done upstream and in cooperation with other Linux and FOSS
distributions where possible.  The priority is on standardization
without the reliance on complicated compatibility layers.

Integrating systemd more deeply into Debian will lead to a more
integrated and tested system, improve standardization of Linux systems,
and bring many new technologies to our users.  Packages can rely upon,
and are encouraged to make full use of, functionality provided by
systemd.  Solutions based on systemd technologies will allow for more
cross-distribution cooperation.  The project will work on proposals and
coordinate transitions from Debian-specific solutions where appropriate.

---

Thanks to Enrico Zini, Michael Biebl and others for help with
drafting this proposal.

-- 
Martin Michlmayr
https://www.cyrius.com/


signature.asc
Description: PGP signature

Re: Review of proposals

[Russ Allbery]

Simon Richter  writes:

> No, Sam's interpretation was correct. My assumption was that in the
> other direction it was already obvious that "it should work with
> systemd" was not negotiable and no one was really asking for that. I'm
> not sure we need to spell that out.

Oh, indeed, I misread your message (there is a "not" in there that my eyes
totally skipped twice), and then managed to confuse Sam.  Apologies!

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

Re: Review of proposals

[Simon Richter]

Hi,

On Fri, Nov 29, 2019 at 09:07:58AM -0800, Russ Allbery wrote:

> Sam, I think you misunderstood Simon's concern.  He's not looking for
> guidance for packages that don't work properly with sysvinit.  He's
> looking for guidance for packages that don't work properly with *systemd*
> (the inverse of that problem).

No, Sam's interpretation was correct. My assumption was that in the other
direction it was already obvious that "it should work with systemd" was not
negotiable and no one was really asking for that. I'm not sure we need to
spell that out.

FWIW, I have exactly one program that might run into trouble with systemd,
as it has an in-place upgrade mechanism that will fork() and execve() in
the parent process to have the new binary provide service to new clients
while the existing sessions remain running, but I'm fairly sure that once I
package this, I can find a solution for that as well.

Sam's mail has soothed my main fear that this would create a regulation
vacuum precisely where I'd expect conflict -- packages that can optionally
use a systemd facility like systemd-tmpfiles but have fallback code for
non-systemd setups where that facility is not available. These seem to be
reasonably well defined.

I'm still unsure what that means for packages where systemd support is a
compile time option, and different code gets included depending on the
value of the --with-systemd option. I haven't had time to look at libvirt
in detail, but they have explicit systemd support, integrate into it and
have a strong dependency on systemd-sysv in bullseye, and upstream still
support FreeBSD as a host where no systemd support is available, so that
would be the most likely candidate, and also one that a lot of people
actually care about.

   Simon

Re: Review of proposals

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam, I think you misunderstood Simon's concern.  He's not
Russ> looking for guidance for packages that don't work properly
Russ> with sysvinit.  He's looking for guidance for packages that
Russ> don't work properly with *systemd* (the inverse of that
Russ> problem).

You're correct.
I totally misunderstood the question.
Thanks for pointing this out and sorry for getting it wrong.


For me, whether a package runs when systemd is not pid 1 is not a core
question.  I suspect that natural forces will cause reasonable things to
happen.  For example many maintainers want their packages to work in the
default configuration.

Re: Review of proposals

[Russ Allbery]

Sam Hartman  writes:
>> "Simon" == Simon Richter  writes:

> Simon> Non-init-related facilities are where I'd expect
> Simon> incompatibilities to arise, and it is a bit sad that there is
> Simon> only one amendment that effectively addresses this question
> Simon> -- because if amendment D doesn't win, this GR provides
> Simon> absolutely no guidance on what to do about packages that do
> Simon> not work properly or at all if systemd is not PID 1.

> I actually think all of the options provide guidance on this.

[...]

Sam, I think you misunderstood Simon's concern.  He's not looking for
guidance for packages that don't work properly with sysvinit.  He's
looking for guidance for packages that don't work properly with *systemd*
(the inverse of that problem).

I think Sam's option three effectively addresses this (if supporting other
init systems is not a priority, then such packages are buggy with Debian's
only supported init system, which doesn't necessarily mean that they're
RC-buggy but does mean that they're going to be relegated to a fairly
niche place in the archive).  The other options may not address this very
concretely.

My perception is that such packages are rare, and I don't see any reason
why they would be RC-buggy in any circumstance (Debian has no problem
packaging programs that only work in very special configurations), but
there are some technical questions that I think the GR will leave mostly
unanswered, such as how to declare a meaningful dependency to make it
clear this is the case.

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

Re: Review of proposals

[Russ Allbery]

Simon Richter  writes:

> In my opinion, that question is the core of the argument we're having.
> Daemon startup is effectively solved on the technical side, and the only
> question remaining there is whether including an init script should
> remain mandatory or not.

For the record, just to ensure there isn't a perception of consensus when
there isn't one, I don't agree at all that daemon startup is effectively
solved on the technical side.  From my perspective, there are huge
improvements to daemon startup in systemd compared to even upstart, let
alone older init systems, and I expect even more to be coming.

I say this not because I want to start another debate about this point (I
absolutely do not -- that's what the vote is for), but because I don't
want you to make false assumptions about what people are concerned about.

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

Re: Please wait a bit longer before calling for a vote

[Michael Biebl]

Hi

Am 29.11.19 um 14:46 schrieb Sam Hartman:
>> "Simon" == Simon Richter  writes:
> 
> Simon> While I generally agree with Sam here that it is rather
> Simon> disingenious to add a new option right at the end of the
> Simon> discussion period, I think that having something proposed by
> Simon> the systemd maintainers on the ballot will be worthwhile
> Simon> because they have one of the best vantage points to see
> Simon> future points of contention and whether the GR is likely to
> Simon> guide us through them.
> 
> Martin Pit  has publically stated he's one of the people I reached out
> to in developing my proposals.
> As I understand, he's been active in maintaining systemd both in Ubuntu and 
> Debain.
> 

I was and am very grateful for Martin stepping in to engange in those
discussions, even if he is not that active anymore in Debian/systemd
since he moved to RedHat.
When the initial options for the ballot were proposed, I contacted
Martin privately, that I was not happy with the existing options (I
think that was roughly two weeks ago).
I did not follow debian-vote, because I find those Debian politics very
emotionally draining. I was hoping given my feedback, that Martin would
engage in further discussions to refine the proposals.
This apparently did not happen and was probably too naive from me.
During this week I was contacted via IRC by people who were concerned
about the state of the existing options, as they didn't feel represented
there.
While I was trying to get a text together during the week, I failed to
do so, for which I apologize. So I asked Ansgar, if we could ask you,
Sam, for one week delay.
The reason being, that I did *not* want to propose an option the last
minute. I completely agree with Simon here, this didn't feel right.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Review of proposals

[Sam Hartman]

> "Simon" == Simon Richter  writes:

Simon> Hi,
Simon> On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote:

[regarding declarative facilities]

>> I have heard more than one person say that they are unhappy that
>> the current situation has been blocking specifically this kind of
>> progress.

Simon> In my opinion, that question is the core of the argument
Simon> we're having.  Daemon startup is effectively solved on the
Simon> technical side, and the only question remaining there is
Simon> whether including an init script should remain mandatory or
Simon> not.

Simon> Non-init-related facilities are where I'd expect
Simon> incompatibilities to arise, and it is a bit sad that there is
Simon> only one amendment that effectively addresses this question
Simon> -- because if amendment D doesn't win, this GR provides
Simon> absolutely no guidance on what to do about packages that do
Simon> not work properly or at all if systemd is not PID 1.

I actually think all of the options provide guidance on this.

First of all, under all options currently on the table, programs like
cockpit that are designed for systemd and that have no way of working
without systemd are permitted.  That is, under all five current options,
my reading is such programs are permitted and non-buggy.


If a program is not explicitly designed for systemd by its upstream,
under proposal E, it is RC buggy.
Under proposal A, it is buggy, NMUs are encouraged, but it is not
inherently RC buggy.

Under proposal C, the project has said that supporting multiple init
systems is not a priority, so fixing bugs that happen when systemd is
not pid 1 is not a priority.
I think you could still file a wishlist bug for that situation.

Proposal B is also clear:

>Packages may use any systemd facility at the
>package maintainer's discretion, provided that this is consistent with
>other Policy requirements and the normal expectation that packages
>shouldn't depend on experimental or unsupported (in Debian) features
>of other packages.  Packages may include support for alternate init
>systems besides systemd and may include alternatives for any
>systemd-specific interfaces they use.  Maintainers use their normal
>procedures for deciding which patches to include.

That is, the maintainer gets to decide what  facilities they use and how
important it is for their package to work when systemd is not pid 1.

Proposal B involves a commitment to integrating technologies like
elogind into the project, but *not* a commitment to integrating these
technologies into leaf packages.  That is, proposal B is about affirming
Debian as a place where we can experiment with technologies that enable
alternate init systems, while leaving which alternate init systems work
for a given package up to those maintainers.
Proposal B is not the option you want if you value sysvinit or runit as
a general purpose init system in Debian.

--Sam

Re: Please wait a bit longer before calling for a vote

[Martin Pitt]

Hello all,

Sam Hartman [2019-11-29  8:46 -0500]:
> > "Simon" == Simon Richter  writes:
> 
> Simon> While I generally agree with Sam here that it is rather
> Simon> disingenious to add a new option right at the end of the
> Simon> discussion period, I think that having something proposed by
> Simon> the systemd maintainers on the ballot will be worthwhile
> Simon> because they have one of the best vantage points to see
> Simon> future points of contention and whether the GR is likely to
> Simon> guide us through them.
> 
> Martin Pit  has publically stated he's one of the people I reached out
> to in developing my proposals.
> As I understand, he's been active in maintaining systemd both in Ubuntu and 
> Debain.

More like "had been active" -- I don't find much time any more to maintain
systemd in Debian, I'm afraid. Mostly because of IRL/work things, not for
reasons within Debian itself.

Yes, I was part of that discussion from the beginning, but I haven't heard from
Michael about this either, i. e. I don't know what he wants to propose.

Martin

Re: Review of proposals

[Holger Levsen]

On Fri, Nov 29, 2019 at 01:47:18PM +, Ian Jackson wrote:
> I was of course speaking metaphorically.  

I understand, but I think it gets lost.

> I note that the very word
> "flamewar" which you use yourself has the same problem, at least
> etymologically.

haha, right, though just etymologically. But we all have different
images in mind when we think 'war' and 'flamewar'. At least I hope ;)

It certainly was a big bad flamewar :-(

> But I'm happy to try to avoid this kind of terminology, for the
> reasons you give.  So, sorry (and if I do it again please point it out
> again).

Thanks, very much & no problem.


-- 
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: Please wait a bit longer before calling for a vote

[Simon Richter]

Hi Sam,

On Fri, Nov 29, 2019 at 08:46:31AM -0500, Sam Hartman wrote:

> Martin [Pitt] has publically stated he's one of the people I reached out
> to in developing my proposals.
> As I understand, he's been active in maintaining systemd both in Ubuntu and 
> Debain.

Indeed, most of my interactions with systemd maintainers have been with
either Michael or Martin.

It might be helpful at this point to know the general direction of the
planned amendment, even if the wording is not final.

   Simon

Re: Typo in proposal B

[Martin Michlmayr]

* Sam Hartman  [2019-11-29 07:13]:
> Ian> I think this is a subjunctive.
> 
> I agree with Ian.

Thanks for the clarification!  You learn something new every day.

-- 
Martin Michlmayr
https://www.cyrius.com/

Re: Review of proposals

[Ian Jackson]

Holger Levsen writes ("Re: Review of proposals"):
> Ian, could you please stop characterizing those stupid flamewars and mud
> fights as war? War is something completly different, people die.

I was of course speaking metaphorically.  I note that the very word
"flamewar" which you use yourself has the same problem, at least
etymologically.

But I'm happy to try to avoid this kind of terminology, for the
reasons you give.  So, sorry (and if I do it again please point it out
again).

Thanks,
Ian.

-- 
Ian JacksonThese 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.

Re: Please wait a bit longer before calling for a vote

[Sam Hartman]

> "Simon" == Simon Richter  writes:

Simon> While I generally agree with Sam here that it is rather
Simon> disingenious to add a new option right at the end of the
Simon> discussion period, I think that having something proposed by
Simon> the systemd maintainers on the ballot will be worthwhile
Simon> because they have one of the best vantage points to see
Simon> future points of contention and whether the GR is likely to
Simon> guide us through them.

Martin Pit  has publically stated he's one of the people I reached out
to in developing my proposals.
As I understand, he's been active in maintaining systemd both in Ubuntu and 
Debain.

Re: Please wait a bit longer before calling for a vote

[Simon Richter]

Hi,

On Fri, Nov 29, 2019 at 01:22:37PM +, Holger Levsen wrote:

> > I do not support delaying the CFV for an option that has not gained 
> > sponsors.

> just sigh.

> Michael, I'm very very likely to sponsor anything you have written so
> far. Please publish something so it's on the table and Sam cannot argue
> like he does.

While I generally agree with Sam here that it is rather disingenious to add
a new option right at the end of the discussion period, I think that having
something proposed by the systemd maintainers on the ballot will be
worthwhile because they have one of the best vantage points to see future
points of contention and whether the GR is likely to guide us through them.

So I'd also very likely sponsor such an amendment, even this late.

   Simon

Re: Review of proposals

[Holger Levsen]

On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote:
> > For those reasons, I am not sure if I will rank proposal D above FD. I
> > would very much prefer if it were compressed to a proposal of about the
> > same length as proposals B or C.
> I am sorry it is so long, indeed.  It's just that I don't see what to
> cut.  The init systems wars have been so wide-ranging and demonstrated
> a large variety of different pathologies, and poor arguments, as well
> as of course high-level differences of approach.
 
Ian, could you please stop characterizing those stupid flamewars and mud
fights as war? War is something completly different, people die.

In my book, speaking of 'init systems wars' is a CoC violation (utterly
insulting some) which your very proposal D reminds us not to do.


(and btw, I'm very glad that this thread went on so long without mentioning
the war. I do think we as community have improved, greatly, and I'm thankful 
to every individual contributing to this. So I also don't particular mind 
this offense now.)


-- 
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: Review of proposals

[Holger Levsen]

On Thu, Nov 28, 2019 at 07:18:37PM +0100, Lucas Nussbaum wrote:
> Ordering
> 
> In order to save voters' time by making it possible to read proposals in
> a more sensible order, I think they should be re-ordered as:
> 
> Proposal E / Choice 5: Support for multiple init systems is Required
> Proposal D / Choice 4: Support non-systemd systems, without blocking progress
> Proposal A / Choice 1: Support for multiple init systems is Important
> Proposal B / Choice 2: Systemd but we support exploring alternatives
> Proposal C / Choice 3: Focus on systemd for init system and other facilities
> 
> (or the reverse, which has the advantage of only permutating between
> Sam's proposals, which might be more procedurally acceptable)
 
I wholeheartly support this.

(and the rest of what Lucas wrote here, but providing a sensible
ordering is the most important bit of it. Thank you very much for this
review, Lucas!)


-- 
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: Please wait a bit longer before calling for a vote

[Holger Levsen]

On Fri, Nov 29, 2019 at 08:11:48AM -0500, Sam Hartman wrote:
[...] 
> I do not support delaying the CFV for an option that has not gained sponsors.

just sigh.

Michael, I'm very very likely to sponsor anything you have written so
far. Please publish something so it's on the table and Sam cannot argue
like he does.


-- 
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: Please wait a bit longer before calling for a vote

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> Hi, I would like to ask people to wait a bit longer before
Ansgar> calling for a vote.  Michael Biebl said he is looking into
Ansgar> drafting an alternative, but has been too busy with work in
Ansgar> the last few days.  He would therefore like to have a bit
Ansgar> more time to prepare.

I'm sorry, but I've been trying to work with Michael for a number of
months to get his input on these issues.  He has told me that the
problem is not me, but that even answering the question of why
responding to the mails I have sent is too emotionally difficult to
engage in.

He's been aware that I'm considering this issue since  September and has
known that I planned to propose a GR since my September/October bits
mail.


Michael has been invited to engage in this process repeatedly, but has
chosen not to do so.  There's nothing wrong with that.  We are all
volunteers.

However, when you choose to not engage with a discussion, you need to
gracefully accept that you lose influence.
Doing anything else means that you're trying to block the work of others
in a very disrespectful manner.

But there is a huge problem with trying to block forward motion at the
last minute with
a completely new option that no one has seen.

In this instance, blocking on Michael would be implementing exactly one
of the negative patterns Ian talks about in his proposal.

As we've discussed before, there are two significant costs to waiting:

* Many people have talked about the high costs of these discussions.
   I've seen comments to that effect on debian-devel and from multiple
   people on IRC.  There have been a lot of emails in this discussion.
   Following this has been a significant cost for all of us.   Dragging
   that out has costs.

* Delaying the CFV runs into significant  chance of having most of the
  vote be up against the holidays, making it harder for people to vote.
  Delaying the CFV into January leaves the discussion open way too long
  at least if you value  the concerns raised about the cost of the
  discussion.

Depending on how the discussion between Lucas and Ian goes, I can see
delaying the CFV for a couple of days while they hammer out amendments.

People who want to wait are free to rank further discussion above other
options.
You can still express your preferences among the existing options while
ranking further discussion first.

I do not support delaying the CFV for an option that has not gained sponsors.


signature.asc
Description: PGP signature

Please wait a bit longer before calling for a vote

[Ansgar]

Hi,

I would like to ask people to wait a bit longer before calling for a
vote.  Michael Biebl said he is looking into drafting an alternative,
but has been too busy with work in the last few days.  He would
therefore like to have a bit more time to prepare.

Ansgar

Re: Typo in proposal B

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Martin Michlmayr writes ("Typo in proposal B"):
>> "It is important that the project support the efforts"
>> 
>> s/support/supports/?
>> 
>> (I know British and American English don't agree whether an
>> organization is singular or plural but it seems to me that "the
>> project" is singular.)

Ian> I think this is a subjunctive.

I agree with Ian.
I tend to try and write in Chicago Style except where I disagree with
that style (for example their approach to gender is more conservative
than meets the needs of audiences I write for).
I considered spending a while with the grammar section of CMOS 17 last
night to decide  support and supports both sound correct to me.  My
first guess is the same as Ian's: I think that is subjunctive rather
than indicative mood.
However, I realized that at the point where I'm considering spending 30
minutes with a style guide, we've already won.  We've already reached
the quality necessary for a GR.

Re: Review of proposals

[Simon Richter]

Hi,

On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote:

> > For example, it raises a (probably valid) concern about
> > "non-init-related [declarative] systemd facilities", but:

> > 1/ it mixes it with an argument that declarative facilities are better.
> > Well, maybe I can agree with that. I'm not sure it's something
> > the project needs to issue a statement on through a GR.

> I have heard more than one person say that they are unhappy that the
> current situation has been blocking specifically this kind of
> progress.

In my opinion, that question is the core of the argument we're having.
Daemon startup is effectively solved on the technical side, and the only
question remaining there is whether including an init script should remain
mandatory or not.

Non-init-related facilities are where I'd expect incompatibilities to
arise, and it is a bit sad that there is only one amendment that
effectively addresses this question -- because if amendment D doesn't win,
this GR provides absolutely no guidance on what to do about packages that
do not work properly or at all if systemd is not PID 1.

At the same time, it is fairly obvious to me that a commercially backed
project with full-time developers will move faster than the
volunteer-driven alternatives, so I expect lots of these incompatibilities
to pop up in a short time, and resolving them will take quite a while
longer.

   Simon

Re: Typo in proposal B

[Ian Jackson]

Martin Michlmayr writes ("Typo in proposal B"):
> "It is important that the project support the efforts"
> 
> s/support/supports/?
> 
> (I know British and American English don't agree whether an
> organization is singular or plural but it seems to me that
> "the project" is singular.)

I think this is a subjunctive.

Ian.

-- 
Ian JacksonThese 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.

Re: Review of proposals

[Ian Jackson]

Lucas Nussbaum writes ("Review of proposals"):
> In Proposal D:

Hi.  Thanks for the review.

> Concern about length of proposal D
> ==

I'm going to deal with this first.

> I am a bit concerned about the length of proposal D, and the fact that
> it is both very detailed and very vague.

It's detailed about process.  This is because my experiences over the
past few years have been that process has been a problem.

> For example, it raises a (probably valid) concern about
> "non-init-related [declarative] systemd facilities", but:
> 
> 1/ it mixes it with an argument that declarative facilities are better.
> Well, maybe I can agree with that. I'm not sure it's something
> the project needs to issue a statement on through a GR.

I have heard more than one person say that they are unhappy that the
current situation has been blocking specifically this kind of
progress.

> 2/ It says:
> > If policy consensus cannot be reached on such a facility, the
> > Technical Committee should decide based on the project's wishes
> > as expressed in this GR.
> 
> Well, given that some of the criterias are not super-clear (see above),
> it's likely that policy consensus will be hard to reach. Then the TC is
> left with deciding based on the project's wishes as expressed in this
> GR. But assuming that proposal D wins, where is that project's wish on
> non-init-related declarative systemd facilities expressed?

That is referring to the list of criteria in my clause 9
(contextualised bn with the rest of of the whole proposal including
(for example) the principles in clauses 1 and 2).

What this is saying is that if we can't get policy consensus on
whether the clause 9 criteria are met, the TC should decide the same
question.

I'm sorry that this isn't clear to you.  I'd be happy to improve that.

> I'm also not sure about the part about "being excellent to each other".
> How does this part of this GR interact with the CoC? Is it expected that
> the CoC includes special cases about init systems if this proposal wins?

I think your criticism here is addressed primarily at my clause 11.

Directly in answer to your question, no.  If I wanted to modify the
CoC I would say so explicitly.  The CoC is quite generic, whereas this
GR is quite specific.  I don't know if you have been hanging around on
-devel and reading the discussions there ?  Clause 11 is trying to
address some of the specific pathologies we see in those discussions.

Do you see the same pathologies ?  If so, what do you think should be
done to try to address them ?  The existing CoC etc. do not seem to be
effective.

> For those reasons, I am not sure if I will rank proposal D above FD. I
> would very much prefer if it were compressed to a proposal of about the
> same length as proposals B or C.

I am sorry it is so long, indeed.  It's just that I don't see what to
cut.  The init systems wars have been so wide-ranging and demonstrated
a large variety of different pathologies, and poor arguments, as well
as of course high-level differences of approach.

I'm open to further conversation on this.

> I don't understand this part:

> > 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
> > - the facility is better than the other approaches available in Debian, for 
> > example by being more declarative
> > - it is reasonable to expect developers of non-systemd systems including 
> > non-Linux systems to implement it
> > - including consideration of the amount of work involved
> >
> > the facility should be documented in Debian Policy (by textual 
> > incorporation, not by reference to an external document).
> 
> I don't understand the role of the last item ("including consideration
> of the amount of work involved") and it doesn't sound grammatically
> correct to me. The first four items are formulated as criterias, but not
> that one. Should it be rewritten as, for example: "the amount of work
> involved in implementing alternate implementations is reasonable"?

The grammar is a bit awkward because as you say the last entry on the
list is not a criterion.  I want the question of the amount of work to
"cut both ways" and affect the reading of the whole clause.  For
example, if the amount of work is very small, then a very nugatory
specification, or a very minor improvement, might be sufficient.

I don't want to pull that item out of the list; the list is a set of
things to consider.  But maybe it could be reworded.

Thanks,
Ian.

-- 
Ian JacksonThese 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.

Re: Typo in proposal D [and 2 more messages]

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin Michlmayr writes ("Typo in proposal D"):
> "which is not the what the user wanted"
> 
> "not the what": s/the//

Obviously, this is a good fix and doesn't change the meaning.  Kurt,
can you please adjust the text of my proposal D ?  (I hereby propose
and/or accept this as necessary.)

Martin Michlmayr writes ("Re: Typo in proposal D"):
> * Kurt Roeckx  [2019-11-29 00:39]:
> > > The proposal also contains Markdown syntax (**, ``) which imho should
> > > be converted to HTML on the web site.
> > 
> > If Ian can confirm that the intention is to render this in italic,
> > I'm happy to change the *s.
> > 
> > I'm not sure what you mean with the ``.
> 
> It's used here:
> bugs with severity `serious'.
> 
> Normally `` is used for code or fixed-width font in Markdown.
> I now see it's atually `...', so a real quotation mark, but I think
> you should use serious since the `...' looks weird
> on an HTML page.

Martin is correct.  My intent here was to simply to use matched quotes
(according to ASCII as defined in, for example RFC-20).  Unfortunately
ISO-646 is not compatible with ASCII.  I should write this up
properly some time.

For correct HTML rendering,   is right.

> > I don't think I can make any changes related to typos.
> 
> Ok, I'm not familiar with procedures but seems strange not to fix
> obvious typos.  It's not like I'm proposing editorial changes *cough* :P

I think what Kurt means is that he is not, even with his secretary hat
on, able to make changes himself.  Changes must be formally proposed,
and accepted by the proposer.

Ian.
-BEGIN PGP SIGNATURE-

iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3hAVQgHGlqYWNrc29u
QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTls1QgAl5e/F/7U7bYG
Mds1vgD2O5cUN2wcnMnaBDz7Ru8FZ2MZxEhOQJQmW2yCOy7sDdPnoa4MZ6J7pbIZ
oJBAG/eQo2LOYrvPnr3DpIMO7jGi92n314QPDg+HmK0MncI7H6e07Oi+qp/pyuMB
J5oMZFrV4losOrkIB0VwPnRBSCkaDsn9tVNpOPQAwlDOBAG4/tzC2RIZAFKAd2gr
S3x5kIlqyEL53QTHTWpmLI7py6o5FjyBkOi8fUUPs5NqPR5vPP64EKR1t6T9GsiW
QDceegXTdfg5aElUFveUxutcnjpsPmU2tHj++/Vjms2fP399QuUIrCJ5nCZlpuIw
uFzXx3KafQ==
=Igu8
-END PGP SIGNATURE-

-- 
Ian JacksonThese 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.

Re: Typo in proposal D

[Martin Michlmayr]

* Kurt Roeckx  [2019-11-29 00:39]:
> > The proposal also contains Markdown syntax (**, ``) which imho should
> > be converted to HTML on the web site.
> 
> If Ian can confirm that the intention is to render this in italic,
> I'm happy to change the *s.
> 
> I'm not sure what you mean with the ``.

It's used here:
bugs with severity `serious'.

Normally `` is used for code or fixed-width font in Markdown.
I now see it's atually `...', so a real quotation mark, but I think
you should use serious since the `...' looks weird
on an HTML page.

> I don't think I can make any changes related to typos.

Ok, I'm not familiar with procedures but seems strange not to fix
obvious typos.  It's not like I'm proposing editorial changes *cough* :P

-- 
Martin Michlmayr
https://www.cyrius.com/