Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Guillem Jover]

On Fri, 2019-12-06 at 22:50:32 +0100, Kurt Roeckx wrote:
> That's 5, I'll update everything.

Thanks for this Kurt! Much appreciated!

Regards,
Guillem

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Jonas Smedegaard]

Quoting Kurt Roeckx (2019-12-06 23:06:28)
> On Fri, Dec 06, 2019 at 10:50:32PM +0100, Kurt Roeckx wrote:
> > 
> > That's 5, I'll update everything.
> 
> The website should be updated very soon.

Thanks a lot, Kurt!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Ricardo Mones]

On Fri, Dec 06, 2019 at 09:51:50PM +0100, Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
> 
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> 
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> 
> I'm CCing all the previous sponsors explicitly, just in case.
> 
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<
> 
> 
> Thanks,
> Guillem

Seconded.

best regards,
-- 
  Ricardo Mones 
  ~
  RTFM - "Read The Manual" (The 'F' is silent). Usually a very good 
  idea. Bjarne Stroustrup



signature.asc
Description: PGP signature

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Kurt Roeckx]

On Fri, Dec 06, 2019 at 10:50:32PM +0100, Kurt Roeckx wrote:
> 
> That's 5, I'll update everything.

The website should be updated very soon.


Kurt

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Alberto Gonzalez Iniesta]

On Fri, Dec 06, 2019 at 09:51:50PM +0100, Guillem Jover wrote:
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded.

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


signature.asc
Description: PGP signature

Re: Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Scott Kitterman]

On Friday, December 6, 2019 3:59:43 PM EST Kurt Roeckx wrote:
> On Fri, Dec 06, 2019 at 09:04:39PM +0100, Guillem Jover wrote:
> > Hi!
> > 
> > Ok, so here's what I'd like (or would have liked) to get into the ballot,
> > given the new context after the addition of the combined D+G option. But
> > it's not very clear to me whether this will be acceptable or not to the
> > Secretary, and what would be the actual procedure to replace the existing
> > option G with this one (as long as enough of the original sponsors are
> > fine with it), as I've found the way the procedure was applied/interpreted
> > to be rather confusing or perhaps not matching my memory of previous
> > instances.
> 
> You're really cutting this short, sending an email 4 hours before the
> vote starts, and we're not at 3 hours before the start. I'm going to
> need to see at least 5 people seconding this update before 23 UTC,
> so 2 hours left, to allow this update.

I count there are 5 now.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Kurt Roeckx]

On Fri, Dec 06, 2019 at 04:48:48PM -0500, Scott Kitterman wrote:
> 
> Seconded.

That's 5, I'll update everything.


Kurt

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Scott Kitterman]

On Friday, December 6, 2019 3:51:50 PM EST Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
> 
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> 
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> 
> I'm CCing all the previous sponsors explicitly, just in case.
> 
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded.

Scott K


signature.asc
Description: This is a digitally signed message part.

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Adam Borowski]

> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded.

-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.


signature.asc
Description: PGP signature

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Kyle Robbertze]

Hi

On 2019/12/06 22:51, Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
> 
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> 
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> 
> I'm CCing all the previous sponsors explicitly, just in case.
> 
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



signature.asc
Description: OpenPGP digital signature

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Mathias Behrle]

* Guillem Jover: " Option G update [signed] (was Re: Proposal: Reaffirm our
  commitment to support portability and multiple implementations)" (Fri, 6 Dec
  2019 21:51:50 +0100):

> [ Sorry, resending signed this time around. :/ ]
> 
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> 
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> 
> I'm CCing all the previous sponsors explicitly, just in case.
> 
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<
> 
> 
> Thanks,
> Guillem

Seconded.

-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgppRqJLqo0LT.pgp
Description: Digitale Signatur von OpenPGP

Re: Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Kurt Roeckx]

On Fri, Dec 06, 2019 at 09:04:39PM +0100, Guillem Jover wrote:
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.

You're really cutting this short, sending an email 4 hours before the
vote starts, and we're not at 3 hours before the start. I'm going to
need to see at least 5 people seconding this update before 23 UTC,
so 2 hours left, to allow this update.


Kurt

Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Guillem Jover]

[ Sorry, resending signed this time around. :/ ]

Hi!

Ok, so here's what I'd like (or would have liked) to get into the ballot,
given the new context after the addition of the combined D+G option. But
it's not very clear to me whether this will be acceptable or not to the
Secretary, and what would be the actual procedure to replace the existing
option G with this one (as long as enough of the original sponsors are
fine with it), as I've found the way the procedure was applied/interpreted
to be rather confusing or perhaps not matching my memory of previous
instances.

The changes to the original G are:
 - Addition of Principles section title.
 - s/tradeoffs/trade-offs/g.
 - Addition of Guidance section.

I'm CCing all the previous sponsors explicitly, just in case.


X<
Title: Reaffirm our commitment to support portability and multiple 
implementations

Principles
~~

The Debian project reaffirms its commitment to be the glue that binds
and integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.

We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.

We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight trade-offs differently, and have
at the same time different and valid requirements and/or needs fulfilled
by these diverse views.

Following our historic tradition, we will welcome the integration of
these diverse technologies which might sometimes have conflicting
world-views, to allow them to coexist in harmony within our distribution,
by reconciling these conflicts via technical means, as long as there
are people willing to put in the effort.

This enables us to keep serving a wide range of usages of our distribution
(some of which might be even unforeseen by us). From servers, to desktops
or deeply embedded; from general purpose to very specifically tailored
usages. Be those projects hardware related or software based, libraries,
daemons, entire desktop environments, or other parts of the software
stack.

Guidance


In the same way Debian maintainers are somewhat constrained by the
decisions and direction emerging from their respective upstreams,
the Debian distribution is also somewhat constrained by its volunteer
based nature, which has as another of its core defining traits, not
willing to impose work obligations to its members, while at the same
time being limited by its members bounded interests, motivation, energy
and time.

Because of these previous constraints, trying to provide guidance in
a very detailed way to apply the aforementioned principles, is never
going to be satisfactory, as it will end up being inexorably a rigid
and non-exhaustive list of directives that cannot possibly ever cover
most scenarios, which can perpetuate possible current tensions.

These will always keep involving case by case trade-offs between what
changes or requests upstreams might or might not accept, or the upkeep
on the imposed deltas or implementations the Debian members might need
to carry on. Which can never be quantified and listed in a generic and
universal way.

We will also keep in mind that what might be considered important for
someone, might at the same time be considered niche or an uninteresting
diversion of time for someone else, but that we might end up being on
either side of the fence when sending or receiving these requests.

We will be guided, as we have been in many other Debian contexts in the
past, by taking all the above into account, and discussing and evaluating
each situation, and respecting and valuing that we all have different
interests and motivations. That is in our general interest to try to
work things out with others, to compromise, to reach solutions or find
alternatives that might be satisfactory enough for the various parties
involved, to create an environment where we will collectively try to
reciprocate. And in the end and in most cases it's perhaps a matter of
just being willing to try.
X<


Thanks,
Guillem


signature.asc
Description: PGP signature

Re: Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Jonas Smedegaard]

[ dropping all recipients except debian-vote@l.d.o ]

Quoting Guillem Jover (2019-12-06 21:04:39)
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Guillem Jover]

Hi!

Ok, so here's what I'd like (or would have liked) to get into the ballot,
given the new context after the addition of the combined D+G option. But
it's not very clear to me whether this will be acceptable or not to the
Secretary, and what would be the actual procedure to replace the existing
option G with this one (as long as enough of the original sponsors are
fine with it), as I've found the way the procedure was applied/interpreted
to be rather confusing or perhaps not matching my memory of previous
instances.

The changes to the original G are:
 - Addition of Principles section title.
 - s/tradeoffs/trade-offs/g.
 - Addition of Guidance section.

I'm CCing all the previous sponsors explicitly, just in case.


X<
Title: Reaffirm our commitment to support portability and multiple 
implementations

Principles
~~

The Debian project reaffirms its commitment to be the glue that binds
and integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.

We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.

We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight trade-offs differently, and have
at the same time different and valid requirements and/or needs fulfilled
by these diverse views.

Following our historic tradition, we will welcome the integration of
these diverse technologies which might sometimes have conflicting
world-views, to allow them to coexist in harmony within our distribution,
by reconciling these conflicts via technical means, as long as there
are people willing to put in the effort.

This enables us to keep serving a wide range of usages of our distribution
(some of which might be even unforeseen by us). From servers, to desktops
or deeply embedded; from general purpose to very specifically tailored
usages. Be those projects hardware related or software based, libraries,
daemons, entire desktop environments, or other parts of the software
stack.

Guidance


In the same way Debian maintainers are somewhat constrained by the
decisions and direction emerging from their respective upstreams,
the Debian distribution is also somewhat constrained by its volunteer
based nature, which has as another of its core defining traits, not
willing to impose work obligations to its members, while at the same
time being limited by its members bounded interests, motivation, energy
and time.

Because of these previous constraints, trying to provide guidance in
a very detailed way to apply the aforementioned principles, is never
going to be satisfactory, as it will end up being inexorably a rigid
and non-exhaustive list of directives that cannot possibly ever cover
most scenarios, which can perpetuate possible current tensions.

These will always keep involving case by case trade-offs between what
changes or requests upstreams might or might not accept, or the upkeep
on the imposed deltas or implementations the Debian members might need
to carry on. Which can never be quantified and listed in a generic and
universal way.

We will also keep in mind that what might be considered important for
someone, might at the same time be considered niche or an uninteresting
diversion of time for someone else, but that we might end up being on
either side of the fence when sending or receiving these requests.

We will be guided, as we have been in many other Debian contexts in the
past, by taking all the above into account, and discussing and evaluating
each situation, and respecting and valuing that we all have different
interests and motivations. That is in our general interest to try to
work things out with others, to compromise, to reach solutions or find
alternatives that might be satisfactory enough for the various parties
involved, to create an environment where we will collectively try to
reciprocate. And in the end and in most cases it's perhaps a matter of
just being willing to try.
X<


Thanks,
Guillem

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Simon Richter]

Hi,

On Thu, Dec 05, 2019 at 08:32:28AM -0500, The Wanderer wrote:

> At minimum, "X is the default" means "you will get X if you don't take
> any action to avoid doing so". All definitions I can think of seem to
> share that baseline.

> At something like maximum, "X is the default" could be read to mean
> "getting anything other than X is not expected to be possible".

Debian also has a bit of a special role in that it is upstream to other
distributions, including the systemd-only Ubuntu and the
everything-except-systemd Devuan, in addition to being useful as a
standalone distribution, so the definition of "default" concerns not only
our direct, but also indirect users.

   Simon

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[The Wanderer]

On 2019-12-05 at 04:34, Raphael Hertzog wrote:

> Hi,
> 
> On Mon, 02 Dec 2019, Guillem Jover wrote:
> 
>> Reframing -
>> 
>> Why have init systems become such a contentions and toxic issue? I
>> mean yeah, it potentially integrates with many parts of the system,
>> but we do have other components in the distribution with multiple
>> or non-portable implementations, where we have managed to handle
>> them all just fine (at least w/o major conflict)? Say http servers,
>> databases, etc., or Linux specific security frameworks such as SE
>> Linux or AppArmor. We even have multiple implementations of things
>> like shell interpreters, or awk. The exact same thing applies to
>> hardware architectures, some of which have less popcon than say
>> GNU/Hurd or GNU/kFreeBSD!
> 
> It's easier to handle multiple alternatives for optional components.
> You can have a Linux system without any security module or without an
> HTTP server or database server.
> 
> You can't have an OS without a kernel or without an init system. For
> the kernel, we already made it clear that we are primarily about
> Linux, both due to the name of our distribution and with the fact
> that the release architectures. I certainly appreciate the non-Linux
> ports and I'm generally in favor of welcoming those efforts under the
> Debian umbrella as long as they don't impede the rest of the project
> in any substantive way.
> 
> For the init system, we have changed the default but it seems that in
> the minds of many contributors, it should be considered an equal to
> openrc or sysvinit and we should not fully embrace it so that it
> remains equal to the other init systems.

To me, it looks as if this entire thing is an outgrowth and/or another
expression of something which I've seen - and, I think, sometimes
pointed out - as far back as the original "should we change the default
init system?" discussions: people don't have a shared understanding of
what it means for an init system to be the default.


At minimum, "X is the default" means "you will get X if you don't take
any action to avoid doing so". All definitions I can think of seem to
share that baseline.

At something like maximum, "X is the default" could be read to mean
"getting anything other than X is not expected to be possible".

There is a lot of room in between those two, and I believe I've seen
people who seem to be expecting it to mean many different things in that
range. (Just offhand, I can't even tell what meaning you had in mind
when you used the term in the last quoted paragraph above.)

At least from a certain perspective, the various options presented in
this GR - and some of the positions taken in discussion, which may not
have become formal options - can be seen as advocating for various
definitions of "default" within that range.


It has been, and remains, my opinion that until we (preferably) reach
agreement on what is meant by this term in the context of init systems,
or (at least) bring the various definitions being used - if only
implicitly - by different parties/factions/whatever into explicit view,
we will not even be able to have fully meaningful discussions of the
subject, let alone actually reach an agreement which might settle the
larger init-system arguments.

I've been hoping, every time this discussion comes up, that we would
wind up having that explicit conversation about what "default" does or
should mean in this context (although I haven't tried to speak up with
that goal nearly as often as I've had the thought, because I'm not great
at that type of advocacy and it usually seemed like doing so would be
less likely to help than to make the situation worse). Unfortunately, as
far as I can tell, that doesn't seem to have ever happened. This GR
seems to be nearly as close as we've come, and it's still a layer or two
of implicitness away from actually making it explicit.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Raphael Hertzog]

Hi,

On Mon, 02 Dec 2019, Guillem Jover wrote:
> Reframing
> -
> 
> Why have init systems become such a contentions and toxic issue? I mean
> yeah, it potentially integrates with many parts of the system, but we do
> have other components in the distribution with multiple or non-portable
> implementations, where we have managed to handle them all just fine (at
> least w/o major conflict)? Say http servers, databases, etc., or Linux
> specific security frameworks such as SE Linux or AppArmor. We even have
> multiple implementations of things like shell interpreters, or awk. The
> exact same thing applies to hardware architectures, some of which have
> less popcon than say GNU/Hurd or GNU/kFreeBSD!

It's easier to handle multiple alternatives for optional components. You
can have a Linux system without any security module or without an HTTP
server or database server.

You can't have an OS without a kernel or without an init system. For the
kernel, we already made it clear that we are primarily about Linux, both
due to the name of our distribution and with the fact that the release
architectures. I certainly appreciate the non-Linux ports and I'm
generally in favor of welcoming those efforts under the Debian umbrella
as long as they don't impede the rest of the project in any substantive
way.

For the init system, we have changed the default but it seems that in the
minds of many contributors, it should be considered an equal to openrc
or sysvinit and we should not fully embrace it so that it remains equal
to the other init systems. I believe that's the part that needs to be
clarified with this GR:
- (a) either we endorse the fact that we can fully embrace it, accepting
  that we create more work for contributors of alternate init systems
- (b) or we don't want to fully embrace it and we stick to a minimum usage
  of systemd features

I'm firmly in favor of (a) but that doesn't mean that I don't welcome
the contributions of people using alternative init systems and I still
believe that we can host their work within Debian.

>  * Portability and alternatives camp: This proposal. I see it, as allowing
>and welcoming people from both the above camps, as long as they are
>open to constructively cooperate, and accept that these both camps
>exist, their respective technologies have value, and that there are
>people that are fine with using any of these alternatives or at least
>supporting them. And that this makes for a richer and more interesting
>project with different perspectives.

I do believe their respective technologies have value and that Debian
can/should offer those technologies if we have volunteers, but I also
believe that we should not consider all those technologies as equal, and
that when we have to make a choice for the default implementation of a
non-optional component, we should fully embrace it.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Mike Gabriel]

Hi Ian,

On  Di 03 Dez 2019 13:54:40 CET, Ian Jackson wrote:


* Should I adopt Guillem's framing as a preamble to my own proposal ?
  (Should this be a new alternative or a replacement?)

* Would Guillem's framing make a good preamble to Dmitry's option ?

* Or do the supporters of Guillem's option favour some other
  combination of possible answers to the specific questions ?


Personally, I think that the full scope of the tendency spectrum  
regarding init systems is +/- covered by the available proposals.


However, not all proposals provide proper guidance how to act and  
react in certain corner and/or non-corner cases.


I think, this lack of specifics can be amended with a follow-GR that  
goes into details and fine-tunes the voted for proposal.


Personally, I am much more on the multiple init systems side than on  
the systemd side, however, if the majority in Debian wants to see  
systemd-only, you can safe the drafting time today for other valuable  
tasks.


My 2¢,

light+love
Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpyIX_aSZYC3.pgp
Description: Digitale PGP-Signatur

Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Ian Jackson]

In some sense I am asking the same questions as Russ.

Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to 
support portability and multiple implementations)"):
> I've to say, that while I think I understand where your and other similar
> reactions to this proposal are coming from, I also found them a bit
> perplexing. :)

Let me skip to the end:

> The key here, I guess, is that each situation needs to be evaluated
> independently, and no magic decision tree will ever fix trying to work
> things out with other people, in good faith, and trying to find
> solutions or compromises that satisfy others and us too. But maybe this
> is asking too much, dunno. :/
> 
> I understand that not giving apparently detailed guidance might make
> things more difficult for the policy editors, and I'm sorry about that,
> but I think no one ever expected that collaborating in a project such as
> Debian with people pulling in random directions would always be easy?

As you know I very much agree with you about the framing.

But it appears that you don't that we should then, in something like
your proposal, take the principles in that framing and apply them in
to some of the most contentious specific problems facing us today.

In its current state I think your proposal is unlikely to do well.
I am very keen that something with your framing text should do well.

Since you don't seem to agree that your option should be supplemented
by specifics, I would like to ask the rest of the community:

* Should I adopt Guillem's framing as a preamble to my own proposal ?
  (Should this be a new alternative or a replacement?)

* Would Guillem's framing make a good preamble to Dmitry's option ?

* Or do the supporters of Guillem's option favour some other
  combination of possible answers to the specific questions ?

I think they key specific questions are:

Q1 Init scripts.  Possible answers, roughly:

 E  Lack of an init script is an RC bug; maintainers must write
init scripts.

 D  Lack of an init script is not an RC bug but contributions of init
scripts should be filed as RC bugs.  Ie the non-systemd community
must write them but maintainers must accept them.

 All other options [1]
Lack of an init script is a normal or wishlist bug and
maintainers can block them because they want systemd
hegemony.

Q2 sysusers.d, systemd timer units, etc.

 E  May not be used (RC bug) unless a non-systemd-pid-1
implementation is available.  Ie proponents of these
interfaces must write the non-systemd variant.

 D  Can be standardised in policy and used but only if they (i) are
any good (ii) can sensibly exist for non-systemd.  Ie, the
non-systemd community must write the non-systemd variant, but they
will get the time to do so.

 All other options [1]
Everyone is allowed to use them willy-nilly and non-systemd
support will rot.

Q3 dependencies which cause init system switching etc.

 E,D
Forbiddden

 All other options [1]
Allowed.  Theoretical degradations of dependencies on systemd
systems will continue to make it really hard to install and
maintain non-systemd ones.

I have written this mail To people who seconded Guillem's proposal and
to some people from the thread.  I would particularly like to hear
your views.

I am considering making a formal variant of Guillem's proposal, which,
if Guillem doesn't agree that specific guidance is needed, would stand
on the ballot alongside Guillem's and my proposal D.  I would like
that proposal to reflect the views of people who seconded Guillem's
proposal.

Thanks
Ian.

[1] Sam's B "Support for multiple init systems is Important" appears
to allow NMUs to provide init scripts and to use alternatives to
systemd facilities but it says "According to the NMU guidelines".  The
NMU guidelines forbid NMUs when the maintainer has explicitly said
they do not want a particular change.  So in practice a maintainer who
does not want an init script in their package can block this and the
only possible recourse is to the TC, which is not suitable and not
effective.

-- 
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: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Mon, 02 Dec 2019 at 00:28:54 +0100, Simon Richter wrote:
> Wasn't there a plan to add support for containers managed through
> systemd that have filtered access to the system dbus, or is that just a
> special case of a service unit?

As a general rule, "heavyweight" containers with their own init system
that behave like a lighter-weight alternative to VMs (notably lxd and
some uses of systemd-nspawn) have their own set of D-Bus buses managed
by their own init system and process tree, the same as if they were a VM;
while "lightweight" containers that behave more like a chroot (like Docker
and some uses of systemd-nspawn) or a restricted view of the host system
(like most bubblewrap-based containers) either share the host system's
buses, or don't have any D-Bus access at all.

Containers managed as system services by systemd-as-pid-1 are outside
any login session or user-session, so it would not be appropriate for
them to access anyone's session bus. They could access the D-Bus system
bus if desired (with or without filtering). If they access the system
bus, I would expect it to be conceptually the same system bus used by
non-contained system services like NetworkManager, but maybe with fewer
things that they are allowed to do.

Flatpak apps in containers have filtered access to the D-Bus session
and/or system bus from the host system. This is conceptually the same
as if they weren't in a container, but with a firewall-style filter
(xdg-dbus-proxy) between the client and the bus. Not everything is
allowed, but everything that *is* allowed behaves the same as if there
was no container: the same number of buses exist, and their scopes are
the same.

As far as I'm aware, Snap apps are approximately the same shape as Flatpak
in this respect: filtered access to the D-Bus session and/or system
bus from the host system (if you're running Ubuntu's kernel patchset
with AppArmor enhancements), or unfiltered access (otherwise). Again,
this doesn't change the number of buses that exist or what they mean.

smcv


signature.asc
Description: PGP signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Russ Allbery]

I'm going to make a similar point to Sam's but in a slightly different
way that hopefully will help.  (Also, I apologize for sounding rather too
absolute in my initial response to your proposal.  There were better ways
of phrasing my concerns.)

Guillem Jover  writes:

> I'm actually not sure how the other options can be seen as resolving the
> root issue at hand. I see what they are trying to do, but I don't think
> they are framing it correctly. They are all approaching the problem from
> the symptoms, by either trying to go into details on how to integrate
> specific stuff, or on how to behave. This all feels like they assume
> that people would not respect the spirit of a decision, and to combat
> bad faith they need to be very specific on details? But if we'd assume
> people are going to be acting in bad faith, then no amount of details
> and specifics would fix this, and IMO it can make it worse, as it gives
> a list of things to be looking loop holes into and questioning
> legalities all over. I think this is a recipe for disaster, and I also
> find that type of framing a bit depressing.

This isn't how I think about the options.  I don't think people are going
to behave in bad faith.  Rather, I think the problem is what Sam alluded
to: General statements of principle are more open to interpretation than
their authors think that they are.

With full respect and credit to those who have different goals for this
GR, I personally am largely uninterested in the project making a general
statement of principles about integrating technology.  To be frank, I'm
dubious of such statements.  I don't think they're always helpful.  I also
think the principles of Debian developers are highly diverse (which is
great), and perhaps our goal should not be to try to get everyone in
Debian to align on the same principles, but instead to make practical
decisions that can be supported from a variety of principles.

The problem I want to solve is that we need to make three work-blocking
decisions:

1. Is every package that wants to start a service always, sometimes, or
   never required to include an init script?  If they are, at what bug
   severity and with what consequences if this is not done?

2. Are package maintainers allowed to use systemd-exclusive facilities
   that would improve system integration for systemd users or improve
   other goals (such as security) at the cost of compatibility with other
   init systems?  If so, what process should we use for adopting those
   facilities?

3. How much effort is the project committing to undertaking to incorporate
   alternatives to major systemd ecosystem components (such as elogind)
   that are not drop-in replacements, either due to their own
   implementation limitations or because our dependency system or other
   tools makes drop-in replacement difficult?

As one of the Policy editors, I am primarily concerned with 1 and 2.  I'm
only an interested bystander for 3 (ideally Policy should have something
to say here, but we haven't gotten there).

I see huge value in the project making those decisions without regard to
whether the project can agree on principles underlying those decisions.  I
don't want to argue about interpretation of some general, non-specific
statement.  I want the project to make some decisions.

I believe that we have already exhausted or ruled out other project
mechanisms to make these three critical technical decisions (Policy
process, debian-devel discussion, and the Technical Committee).  I think
delegatd teams and the Technical Committee are (correctly!) unwilling to
speak for the project on these closely-divided and highly divisive issues.

Debian is constituted as a democracy of developers.  The project makes
technical decisions of last resort via vote.

We've put off this decision as long as we reasonably can, we've tried for
five years to let the discussion calm down and to find some alternative
method of reaching consensus, we've waited to see if some
nonconfrontational approach will evolve, and people are still sniping at
each other.  Meanwhile, work that people want to do in Debian, whether
that be better support for non-systemd systems or taking advantage of
valuable systemd features such as ProtectSystem or DynamicUser, is often
blocked on these decisions with no clear prospect for resolution or
unblocking.

You may have noticed in these discussions that I'm not talking about my
own opinion about what the decision could be.  I have an opinion, but I've
spent enough energy attempting to convince other people of my opinions on
init systems for one lifetime.  On this vote, I'm on team "make a decision
already, whatever that decision is," and the position I'm advocating here
is please do not kick the can even farther down the road.


Towards that end, here are the specific implications of the various
options that I anticipate for Policy.  Please note that this is just my
personal opinion as one of the Policy editors.  Sean doubtless 

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> The key here, I guess, is that each situation needs to be
Guillem> evaluated independently, and no magic decision tree will
Guillem> ever fix trying to work things out with other people, in
Guillem> good faith, and trying to find solutions or compromises
Guillem> that satisfy others and us too. But maybe this is asking
Guillem> too much, dunno. :/

Hi.

I strongly agree with the above--that things need to be evaluated on a
situation-by-situation basis.

I'm responding not in the hopes of convincing you or persuading you (or
really anyone else).
It's obvious that we see the world differently.

However, I feel that if I simply said nothing, I would not be respecting
the thought you've put into your proposal and to your position.

So, I'm responding to say that I've tried to listen and understand where
you're coming from, and to show where I think our differences are.
Thanks for the work that you put into this.  While I disagree, I value
what you've done here.

My experience in leading groups to consensus is that it is often much
easier to focus on specific details and specific situations than on
general principles.

It is very easy to get people to  appear to agree when you are talking
about generalities that can be widely interpreted.
However, in practice when you go try and apply those generalities to
specific cases, you find that the same divisions exist and that the
generalities don't help much.
There are exceptions: I think the Social Contract has done significant
good for the project.

In my experience those exceptions tend to be agreements to general
principles not born out of conflict, but rather out of a community's
desire to define itself.

In contrast, when there is conflict, I've found that you get better
results focused on specifics.

But Guillem is right that as we move forward we'll find things where the
specific details we focus on in this GR do not apply.  We'll also find
cases where circumstances have changed, we have new information, or new
ways of thinking about something emerge.

At that point, we can (and I think should) start to derive general
principles from the specifics we adopt in the GR.
I hope we take this GR as the feeling of the project at a single point
in time and accept that things will change.  I hope that we do not force
ourselves to have future GRs to revisit aspects of what we decide in the
coming weeks when we can come to agreement that things have changed.

I respect that this is an area where people can look at the world
differently.  Thanks for placing option G on the ballot: if the project
believes that focusing on principles is the right way forward here, we
now have a way to concretely express that.


signature.asc
Description: PGP signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Marco d'Itri]

guil...@debian.org wrote:

> * The traditional-only way camp: This group outright rejects things
>   like systemd, and other similar technologies. Some of this group was
>   part of Debian in the past, but found a new home in Devuan. People
I read all my emails with mutt (which I used to maintain) and the news
with tin (which I still maintain).
I send all my emails over UUCP.
My desktop is fvwm (with parts of GNOME!)
My terminals are 80x25.
I maintain Fidonet-related software.
My favourite programming language is Perl.
I use IRC all the time and I despise Slack.
I judge people who send HTML emails or top quote or have signatures
longer than 4 lines.

I am quite fond of my traditions but I still recognize the systemic
benefits provided by only supporting systemd: I do not accept for this
issue to be framed as "tradition vs. progress".

-- 
ciao,
Marco

Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Guillem Jover]

Hi!

[ I'm sorry this has gotten a bit long, but I assume I'm going to run out
  of time for any discussion, due to the imposed timeline, so I'm trying
  to put it all upfront. ]

On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote:
> Guillem Jover  writes:
> > I think the current GR is incorrectly framing the problem at hand,
> > as if it was just an init system selection.
> 
> This resonates with me, but...
> 
> > I'm thus proposing the following:
> 
> I find this really appealing as a higher-level statement of values and
> intent, but unfortunately, I don't think the text does anything to help
> resolve the problems that Sam set out to try and tackle with this GR.
> 
> I therefore find myself unwilling to second it, even though on some
> level I would really like to.

I've to say, that while I think I understand where your and other similar
reactions to this proposal are coming from, I also found them a bit
perplexing. :)

Other options
-

I'm actually not sure how the other options can be seen as resolving
the root issue at hand. I see what they are trying to do, but I don't
think they are framing it correctly. They are all approaching the problem
from the symptoms, by either trying to go into details on how to integrate
specific stuff, or on how to behave. This all feels like they assume that
people would not respect the spirit of a decision, and to combat bad faith
they need to be very specific on details? But if we'd assume people are
going to be acting in bad faith, then no amount of details and specifics
would fix this, and IMO it can make it worse, as it gives a list of things
to be looking loop holes into and questioning legalities all over. I think
this is a recipe for disaster, and I also find that type of framing a bit
depressing.


The options that favor focusing on systemd still seem to leave the door
open in appearance to alternatives, but in some kind of false sense of
hope way, due to either the proposed vague hopes or all the conditionals
which depend on maintainer discretion to apply based on the (naturally
insufficient) details provided on those options. It seems like a death
by a thousand cuts, which sets the stage for more frustration and
conflict.

The options that favor init alternatives go into specific details (are
these truly exhaustive enough though?). But they still seem to not be
asking the right question.


Let's skim over the other options:

* Option F

  - The "cross-distro and standardization efforts" mention feels a bit
misleading to me, as this is really restricted to an ecosystem
based on Linux + glibc + systemd. (To clarify, I think this is
obviously a valid stance to take, I mostly take issue in the way
it is presented.)
  - Provides a false sense of hope (see above):
+ "patches _can_ be submitted".

How is this going to prevent the same situations that triggered this
GR?

* Option B

  - Provides a false sense of hope (see above):
+ _Should_ include unit and init scripts.
+ Developers and user _can_ explore and develop alternatives.
+ Developers need to provide the work, but that does not imply others
  will integrate it.
+ Reviewing and discussing patches but obviously not necessarily
  agreeing to them.

How are any of these going to prevent the same situations that triggered
this GR?

* Option A

  - Provides a false sense of hope (see above):
+ Focuses on sysvinit specifics like init script, but does not
  mention other potentially ancillary features upstream might use
  that are not core functionality to the project at hand.
+ The NMU reference looks like a distraction, as it does not fix any
  possible deadlock or blocking, as one can always reject an NMU, or
  revert it.
+ In Debian, policy (in most cases) follows practice, so whether policy
  accepts something does not say much about what maintainers will be
  accepting.

How are any of these going to prevent the same situations that triggered
this GR?

* Option D

  - Goes into much detail about possible conflicting scenarios, but does
it cover them all? This seems inherently non-exhaustive.
  - This encodes very concrete package names and implementation details,
which seem off for a GR.
+ What if the sysvinit maintainers and users agree they want to switch
  to something else on top of sysvinit that does not use traditional
  init scripts?
  - Isn't option D.7 potentially very counterproductive? Mixing regressions
in support with new support seems murky. Also what kind of patch are
we talking about? A 10 liner, or 1 MiB of delta which upstream is not
willing to take, so the burden falls on the Debian maintainers?

* Option E

  - What does the "MUST" and "work" in here really imply? Does this mean
every package must fully support natively all currently available init
systems in Debian (runit, s6, etc)? Or say, the day after this option
wins, 

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ansgar]

Adam Borowski writes:
>   * dependencies on "systemd | other" rather than "other | systemd"; this is
> a no-op on a systemd system (installed by debootstrap before any
> non-base packages) but causes apt to force an init+rc switch elsewhere

It's very likely not a no-op on systemd systems as significantly more
people somehow got systemd-shim installed than had sysvinit-core, see
for example [1] which shows that somehow the "no-op" results in
systemd-shim getting installed (which caused problems in the past).

Just because you don't observe unwanted behavior happening right now on
your system doesn't imply it doesn't exist.  And the unwanted behavior
that you say wouldn't happen (as it is supposedly a "no-op") happens on
a scale larger than the entire sysvinit user base here...

Your policykit-1 example would likely also suffer from this: adding
alternative builds doesn't only complicate packaging, but it makes the
dependency relations more complicated.  As we've seen from systemd-shim
it's hard to get this right (and Debian did not get this right); from
memory the policykit-1 dependencies to support alternatives looked more
complicated and fragile than what we had for systemd-shim, so they would
probably result in unwanted behavior more often.

So the policykit maintainers wanting to avoid these problems is
understandable to me (I don't think trying to force maintainers to
accept such patches via a GR (option D) is a good solution either).
It doesn't really help that you pretend that there are no issues with
complex dependencies (as above). At a certain point it doesn't make
sense to repeat saying that to you.

  [1]: 
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim_installed=on_legend=on=1

>   * recently added lintian warning requiring maintainers to add a redundant
> .service file even if an init script it already there.  It doubles the
> work and makes one of methods not maintainer-tested (some folks won't
> test init scripts, I won't test .service).  And in most cases doesn't
> even bring any good.

Having multiple init systems that all just call the same sysvinit script
without taking advantage that their native unit type (whatever it is)
provides seems rather uninteresting to me.  It would just mean we get
different implementations that in the end call the same init scripts (so
not "multiple implementations" at all).

What would be the point of providing, for example, openrc be then?

As you don't use systemd I also doubt you would know which (admittedly
mostly minor) annoyances exactly systemd's sysv-compat layer can cause
and would prefer if you didn't try to block people from improving
things.

Really, going back to a "should we really ship systemd units" discussion
makes me wish we would just drop sysvinit completely so we don't have to
restart any discussion from zero (or the point where any alternative
init system was added to Debian).

Ansgar

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Mon, 02 Dec 2019 at 04:26:53 +0100, Simon Richter wrote:
> My expectation was that with systemd, dbus activation functionality
> would have moved into the main systemd binary for better process
> tracking and to avoid code duplication with the other activation methods.

Yes ish, but on an opt-in basis (the D-Bus service integration file has to
refer to the corresponding systemd unit file via the SystemdService key).
Many (most?) system services and some session/user services do this.

For session/user services, this is only done when dbus-user-session is
in use - otherwise, the scope of the dbus-daemon and the scope of
`systemd --user` would be different, making it inappropriate to turn
D-Bus services into systemd user services.

On a systemd system, running systemd-cgls will show you which D-Bus
services have been delegated to systemd (they have their own cgroup
alongside dbus.service) and which ones have not (they are part of
the same cgroup as dbus-daemon).

smcv

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

Hi,

On 02.12.19 00:20, Simon McVittie wrote:

>> In that particular case, the user session must be available to allow
>> activation of gsettingsd via dbus

> There is no such thing as gsettingsd. Presumably you mean dconf-service
> (which is conceptually one of many backends, although in practice it's
> the one that is nearly always used).

Yes, that was multi-stage confusion, gsettingsd hasn't existed for
several years now and also did something else back then -- it just
happened to usually be the first program retrieving settings from the
configuration backend, which is why I still associate it with that
interface.

[...]

Thanks for the diagram, that cleared a few things up.

My expectation was that with systemd, dbus activation functionality
would have moved into the main systemd binary for better process
tracking and to avoid code duplication with the other activation methods.

> I would suggest that dependency system representations for D-Bus services
> should probably not be designed by developers for whom the contents of
> this message are new information.

Yeah, I'm not particularly keen on doing that either, especially as I
don't really use it. That was more of a generic statement "this is a new
type of relationship and needs a new relation" than an actual technical
proposal.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Guillem Jover]

Hi!

I've been busy late yesterday and today, and not been able to reply
to some of the questions presented. I've got an early flight in a few
hours, so I'm unable to finish the draft reply I've started but which
I plan to send tomorrow (Monday). Sorry about this, but the rushed
timeline is not very convenient. :(

Thanks,
Guillem

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

Hi,

On 01.12.19 23:24, Simon McVittie wrote:

> dbus-user-session is not, and probably will not be, usable on non-systemd
> systems. If per-user service managers other than `systemd --user` exist
> and can be configured to provide equivalent semantics, I'd be happy
> to review the necessary integration files, but at the moment there
> is no way to have the semantics represented by dbus-user-session on a
> non-systemd system.

Yes, I feel pretty confident in predicting that this interface will not
be implemented by alternative implementations. The objections to systemd
that I've heard so far are with the design, not the implementation, and
the semantics of this interface only work with this particular design.

>>> It wouldn't be a problem in practice to break that dependency chain, as
>>> systemd based installations tend not to be curated on a
>>> package-by-package basis

> It's true that non-systemd-based installations need to be curated to
> remain non-systemd-based; and it's true that because systemd is the
> default init, systems that accept defaults will be systemd-based and
> not strongly curated; but I don't think either of those implies that
> there are no strongly curated systemd-based systems.

Not "none", but I wouldn't expect the average systemd user to deinstall
"dbus-user-session" because it looks unnecessary. The average sysvinit
user on the other hand... :)

> These categories exist:

> * No service manager at all
> - typical for Docker (pid 1 is usually a simple process reaper)
> - typical for chroots (pid 1 is outside the chroot)
> - systemd --user isn't run
> - dbus-user-session doesn't work
> * Various non-systemd service managers (sysv-rc, OpenRC, etc.)
> - systemd --user isn't run
> - dbus-user-session doesn't work
> * systemd as pid 1, but no pam_systemd
> - systemd --user isn't run
> - dbus-user-session doesn't work
> * systemd as pid 1, and pam_systemd is used
> - typical for "full" systems (bare metal, VM, lxd)
> - systemd --user is run
> - dbus-user-session works

Wasn't there a plan to add support for containers managed through
systemd that have filtered access to the system dbus, or is that just a
special case of a service unit?

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Sun, 01 Dec 2019 at 22:14:06 +0100, Laurent Bigonville wrote:
> It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that makes
> systemd the init on the system), not bin:systemd. Here it's dbus-user-session
> that pulls it because it needs a logind (dunno if it works with elogind)
> session opened to have the session bus started when the user logs-in.

dbus-user-session needs the `systemd --user` per-uid service manager to be
run whenever a uid has at least one login session, which is functionality
provided by the combination of the systemd service manager (init system)
with systemd-logind. An implementation of the logind interfaces, such
as elogind, is not sufficient. If I remember correctly, libpam-systemd +
systemd-shim was not sufficient either: that configuration provided the
logind interfaces but not `systemd --user`, just like elogind.

The changelog for dbus_1.12.16-2 documents this as the reason why
this dependency was not changed to default-logind | logind when those
virtual packages were added to Policy.

smcv

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Sun, 01 Dec 2019 at 22:02:31 +0100, Simon Richter wrote:
> In that particular case, the user session must be available to allow
> activation of gsettingsd via dbus

There is no such thing as gsettingsd. Presumably you mean dconf-service
(which is conceptually one of many backends, although in practice it's
the one that is nearly always used).

> dbus-x11 is not a complete solution -- it makes a "session" dbus
> instance available, but without dbus activation of services

This is not true. Any dbus-daemon[1], including the one started by
dbus-x11, provides D-Bus activation (services started on-request as
children of dbus-daemon, which acts as a crude service manager). This
functionality has been present since 2003-2004 for session buses,
depending where you draw the line for it being feature-complete, and
since 2007 for the system bus.

The dbus-x11 problem that is most relevant here[2] is that because the
session bus is run as a child process of (a somewhat arbitrary process
inside) an X11 desktop session, those D-Bus-activated services cannot
be managed by `systemd --user`, even on systems that have it; and
the session bus and its session services are not visible/available to
programs that run as `systemd --user` services, such as gpg-agent. This
is because `systemd --user` is "bigger than" the per-X11-display session
bus provided by dbus-x11, so anything in its scope that tries to connect
to "the" session bus is faced with the question: which session?

Conceptual model of dbus-user-session on systems with `systemd --user`:

"the system" (system services, etc.)
  \- uid 1000
\- systemd --user
\- dbus-daemon
\- D-Bus-activated services without SystemdService=
\- D-Bus-activated services with SystemdService=
\- non-D-Bus-based user services
\- login session 1 (X11)
\- gnome-session, startkde, ~/.xinitrc or equivalent
\- window manager
\- applications
\- login session 2 (sshd)
\- bash or equivalent
\- CLI applications
  \- uid 1001
  \- ... similar tree ...

Login sessions 1 and 2, `systemd --user` services, and `systemd --user`
itself can share and use the dbus-daemon, because it is part of a scope
that is "as large as" both of them.

Conceptual model of dbus-x11 without dbus-user-session:

"the system" (system services, etc.)
  \- uid 1000
\- systemd --user (if present)
\- non-D-Bus-based user services
\- login session 1 (X11)
\- gnome-session, startkde, ~/.xinitrc or equivalent
\- window manager
\- applications
\- dbus-daemon
\- D-Bus-activated services from login session 1
\- login session 2 (sshd)
\- bash or equivalent
\- CLI applications
\- in principle you could have another dbus-daemon here
   if you run dbus-launch manually
 \- D-Bus-activated services from login session 2
  \- uid 1001
  \- ... similar tree ...

Here, login session 1 owns its own dbus-daemon and is the only one that
can see it. `systemd --user` and login session 2 cannot.

The system bus does not have this duality, because there's only one
system bus per system, the same as the init system; so there is no issue
about the init system's service manager role being in a "larger" or
"smaller" scope than the D-Bus system bus.

"uid 1000" and "uid 1001" in the above refer to any uid that currently
has at least one, but perhaps more than one, login session. When I refer
to a "user session" in D-Bus documentation and terminology, this is
what I mean. uid 1000 has a user session; login sessions 1 and 2 are
part of that user session; and so is its `systemd --user`. uid 1001
has a separate user session, containing its own login session(s) and
`systemd --user`. If we imagine uid 1002 exists but does not currently
have any login sessions, then it also does not have a user-session.

I would suggest that dependency system representations for D-Bus services
should probably not be designed by developers for whom the contents of
this message are new information.

smcv

[1] Assuming you have not configured your dbus-daemon with
--disable-traditional-activation at build time; this makes sense for
some constrained embedded systems, which might be Debian derivatives,
but is unlikely to be suitable for a general-purpose distribution
like Debian, and I have no plans to do so.
[2] There are others.

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Sun, 01 Dec 2019 at 11:13:46 -0800, Russ Allbery wrote:
> Simon Richter  writes:
> > Right, but the dependency chain is there to make sure the package is
> > usable on systemd systems
>
> My recollection is that these dependencies are mostly about either making
> sure user sessions are available or that D-Bus is available, right?  (I'm
> fairly sure about user sessions and less sure about D-Bus.)

"Making sure D-Bus is available" is not particularly meaningful, because
the D-Bus system and session buses are distinct. Depending on the package
in question, it might want one or more of:

* the D-Bus system bus is available at all times (except early boot)
- it's a fairly straightforward system service
- depend on dbus (one day I might break this out into a dbus-system-bus
  package, which at the moment is a Provides in dbus)
- any init system can work

* the D-Bus session bus is available in at least X11 login sessions
- it's a per-user or per-X11-display service
- depend on default-dbus-session-bus | dbus-session-bus
- any init system is fine, *if* you use dbus-x11 to implement
  dbus-session-bus
- the default implementation (see below) requires systemd

* the D-Bus session bus is available in all login sessions, *and* has the
  semantics that it is per-uid rather than per-login-session (the "user
  bus", which is "larger than" a single login session)
- it's a per-user service
- depend on dbus-user-session
- this currently requires `systemd --user`, which requires systemd
  as pid 1 *and* systemd-logind (elogind is not enough) and I don't
  see this changing any time soon

dbus-user-session is not, and probably will not be, usable on non-systemd
systems. If per-user service managers other than `systemd --user` exist
and can be configured to provide equivalent semantics, I'd be happy
to review the necessary integration files, but at the moment there
is no way to have the semantics represented by dbus-user-session on a
non-systemd system.

dbus-user-session is not implied by systemd, or even by systemd --user.
Some `systemd --user` services work badly, or not at all, without
dbus-user-session (represented by a Recommends or Depends on it);
but I've gone to some lengths to make sure that if systemd users who
do not rely on those services want multiple parallel X11 sessions,
each with its own per-X11-display D-Bus session bus, they can have that
(by removing dbus-user-session and installing dbus-x11).

> > It wouldn't be a problem in practice to break that dependency chain, as
> > systemd based installations tend not to be curated on a
> > package-by-package basis

It's true that non-systemd-based installations need to be curated to
remain non-systemd-based; and it's true that because systemd is the
default init, systems that accept defaults will be systemd-based and
not strongly curated; but I don't think either of those implies that
there are no strongly curated systemd-based systems.

> Is it possible to have a systemd system that doesn't have these
> properties?  In other words, do these dependencies only matter with other
> init systems, or do they also matter in container scenarios?

These categories exist:

* No service manager at all
- typical for Docker (pid 1 is usually a simple process reaper)
- typical for chroots (pid 1 is outside the chroot)
- systemd --user isn't run
- dbus-user-session doesn't work
* Various non-systemd service managers (sysv-rc, OpenRC, etc.)
- systemd --user isn't run
- dbus-user-session doesn't work
* systemd as pid 1, but no pam_systemd
- systemd --user isn't run
- dbus-user-session doesn't work
* systemd as pid 1, and pam_systemd is used
- typical for "full" systems (bare metal, VM, lxd)
- systemd --user is run
- dbus-user-session works

I hope that clarifies the situation.

smcv

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Laurent Bigonville]

Simon Richter mailto:sjr%40debian.org>> wrote:

> On 01.12.19 02:54, Russ Allbery wrote:
>
> >> Russ> Could you provide some more information about what your
> >> Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
> >> Russ> which has a pretty tiny list of dependencies and shouldn't
> >> Russ> require that systemd be running so far as I know.  Are you
> >> Russ> thinking of test suites that assume systemd is available?
>
> >> pkg-config for systemd is in systemd not libsystemd-dev
>
> > Oh, okay.  Also, I remembered some previous discussion that some libraries
> > end up with dependencies on systemd components for functionality.  Thanks,
> > I think I understand the issue now.
>
> That was a thread I started on debian-devel:
>
> https://lists.debian.org/debian-devel/2019/08/msg00278.html
>
> The resolution of that thread seemed to be that people were mostly fine
> with the dependency chain because every decision in the path makes
> sense, even if the end result does not.
>
> Without the package pin of systemd-sysv at -100, installing the
> "libwxgtk3.0-gtk3-dev" package causes an init system switch for me. With
> the package pin, apt finds no resolution even though one exists (#940965).
It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that
makes systemd the init on the system), not bin:systemd. Here it's
dbus-user-session that pulls it because it needs a logind (dunno if it
works with elogind) session opened to have the session bus started when
the user logs-in.

So I'm not exactly sure why the systemd.pc should be moved to an other
package.

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

Hi,

On 01.12.19 20:13, Russ Allbery wrote:

>> Right, but the dependency chain is there to make sure the package is
>> usable on systemd systems, i.e. we'd have to accept a regression for the
>> systemd case in order to facilitate the non-systemd case, which is what
>> we don't want, or live with unrelated packages changing people's init
>> system, which we also don't want.

> My recollection is that these dependencies are mostly about either making
> sure user sessions are available or that D-Bus is available, right?  (I'm
> fairly sure about user sessions and less sure about D-Bus.)

In that particular case, the user session must be available to allow
activation of gsettingsd via dbus in the user session context, or gtk
cannot save certain user settings, and silently discards them because
there is no other method to save them included in gtk.

dbus-x11 is not a complete solution -- it makes a "session" dbus
instance available, but without dbus activation of services, the
settings daemon must be started through some other mechanism so it is
available. Without systemd, that mechanism would be "gnome-session".

> Is it possible to have a systemd system that doesn't have these
> properties?  In other words, do these dependencies only matter with other
> init systems, or do they also matter in container scenarios?

I'd expect container scenarios with no user login capabilities, so it
doesn't make sense to install dbus-user-session there, so there is a
good reason why user-facing apps would have to declare that dependency,
and it absolutely makes sense to do that centrally from a library that
is only used by user-facing apps.

The container scenario is an afterthought in both technology stacks,
neither systemd nor traditional Unix do well here. If you run
containers, you have your own orchestration framework at the top of the
food chain, and whether that simply executes programs directly or asks
systemd to do it for them is an implementation detail that might change
between container hosts in the same installation.

The container people most likely want minimal dependencies like shared
libraries in the package system, but functional dependencies would cause
too much software to be installed into a container. For example, if I
write a service that logs through a dbus interface instead of syslog, I
would not want an implementation of that interface inside the container,
but on a dbus instance shared between containers. The Debian dependency
mechanism cannot express this in a sensible way at the moment, the
closest we can get is Recommends.

So far, we haven't expressed service dependencies at all, because
packages with such dependencies were only used in specific scenarios,
e.g. a package that requires an SQL database to work would only document
that somewhere and leave the setup to the sysadmin rather than pull in a
database service as a package.

Medium-term I'd expect that we have to create new dependency types:

 - Depends-DBus-System-Service
 - Depends-DBus-Session-Service
 - Provides-DBus-System-Service
 - Provides-DBus-Session-Service

With demand activation through dbus comes the responsibility of the
distribution to populate the local service registry before the
activation request comes in. Our options there are preemptively
installing services so they are registered, or adding a catch-all
service that informs the user through a notification service that a
certain package must be installed for a particular feature to work,
which requires a (smaller) mapping of advertised[1] interfaces to
packages required, both of which would likely be expressed through
package relationships in Debian.

   Simon

[1] https://docs.microsoft.com/en-us/windows/win32/msi/advertisement



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Simon Richter  writes:

> Right, but the dependency chain is there to make sure the package is
> usable on systemd systems, i.e. we'd have to accept a regression for the
> systemd case in order to facilitate the non-systemd case, which is what
> we don't want, or live with unrelated packages changing people's init
> system, which we also don't want.

> It wouldn't be a problem in practice to break that dependency chain, as
> systemd based installations tend not to be curated on a
> package-by-package basis, so the packages would be installed there
> anyway, but we still need a working policy.

My recollection is that these dependencies are mostly about either making
sure user sessions are available or that D-Bus is available, right?  (I'm
fairly sure about user sessions and less sure about D-Bus.)

Is it possible to have a systemd system that doesn't have these
properties?  In other words, do these dependencies only matter with other
init systems, or do they also matter in container scenarios?

> Until a technical solution to find the runtime dependencies caused by
> dbus service activation exists, dependencies in the systemd ecosystem
> will most likely be specified manually by package maintainers, and
> similar dependency chains will likely pop up more and more.

I think the idea of Ian's proposal is that we're explicitly accepting not
being able to represent dependencies properly in our dependency system
until someone comes up with a neat technical solution.  This seems
basically fine to me -- it means that systems will need to install some
packages to be usable and dependencies won't take care of that
automatically, but that's not entirely a new problem in Debian, and while
not ideal, switching people's init systems on package installation seems
much worse.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

Hi Russ,

On 01.12.19 18:16, Russ Allbery wrote:

>> https://lists.debian.org/debian-devel/2019/08/msg00278.html

> This is a point that Ian's proposal specifically addresses by accepting
> the possibility that packages will be installable but not usable on
> non-systemd systems in order to avoid these sorts of dependency chains.

Right, but the dependency chain is there to make sure the package is
usable on systemd systems, i.e. we'd have to accept a regression for the
systemd case in order to facilitate the non-systemd case, which is what
we don't want, or live with unrelated packages changing people's init
system, which we also don't want.

It wouldn't be a problem in practice to break that dependency chain, as
systemd based installations tend not to be curated on a
package-by-package basis, so the packages would be installed there
anyway, but we still need a working policy.

Until a technical solution to find the runtime dependencies caused by
dbus service activation exists, dependencies in the systemd ecosystem
will most likely be specified manually by package maintainers, and
similar dependency chains will likely pop up more and more.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Bernd Zeimetz]

Hi Adam,

On 12/1/19 12:24 AM, Adam Borowski wrote:
> * there's a lot of use cases where systemd fails[1].  This makes it unfit
>   for being the sole init+rc of an universal operating system.

I assume you've opened bugs for all those cases?
If I understand the problems you're mentioning right, they are
- either the same issue with init. For example: cron - init will kill it
at some point, same like systemd. Just that if you'd be using systemd
timers, you could avoid all these issues.
- or a configuration or admin fail (fs/mount issues...)


> * patches fixing non-systemd regressions are routinely ignored[2]

Not having non-systemd init systems would fix this.

> * changes I view as done with spite, which bring no or negligible benefit to
>   systemd yet large detriment to other rc systems[3]

same here, get rid of init and imprve systemd instead of wasting
people's time in maintaining several init systems. Or wasting other
peole's time as you don't test your service files...


> On the other hand, you cannot require contributors to implement something
> they don't care about nor have required hardware/etc for. 

yes, we can. We have various architectures people don't have at home and
a policy that enforces things people might not like. Nothing unusual
here. That is the way how all bigger projects work - live with them or
choose a different place to work at.


Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Simon Richter  writes:

> That was a thread I started on debian-devel:

> https://lists.debian.org/debian-devel/2019/08/msg00278.html

> The resolution of that thread seemed to be that people were mostly fine
> with the dependency chain because every decision in the path makes
> sense, even if the end result does not.

> Without the package pin of systemd-sysv at -100, installing the
> "libwxgtk3.0-gtk3-dev" package causes an init system switch for me. With
> the package pin, apt finds no resolution even though one exists
> (#940965).

This is a point that Ian's proposal specifically addresses by accepting
the possibility that packages will be installable but not usable on
non-systemd systems in order to avoid these sorts of dependency chains.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

On 01.12.19 02:54, Russ Allbery wrote:

>> Russ> Could you provide some more information about what your
>> Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
>> Russ> which has a pretty tiny list of dependencies and shouldn't
>> Russ> require that systemd be running so far as I know.  Are you
>> Russ> thinking of test suites that assume systemd is available?

>> pkg-config for systemd is in systemd not libsystemd-dev

> Oh, okay.  Also, I remembered some previous discussion that some libraries
> end up with dependencies on systemd components for functionality.  Thanks,
> I think I understand the issue now.

That was a thread I started on debian-devel:

https://lists.debian.org/debian-devel/2019/08/msg00278.html

The resolution of that thread seemed to be that people were mostly fine
with the dependency chain because every decision in the path makes
sense, even if the end result does not.

Without the package pin of systemd-sysv at -100, installing the
"libwxgtk3.0-gtk3-dev" package causes an init system switch for me. With
the package pin, apt finds no resolution even though one exists (#940965).

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ian Jackson]

Ian Jackson writes ("Re: Proposal: Reaffirm our commitment to support 
portability and multiple implementations"):
> I think your proposal would work well as a preamble to many of the
> other options, notably mine and Dmitry's.

I've read the rest of the thread now.  I think Adam Borowski's ideas
may well be fruitful as a basis for making your proposal specific.

I am resisting the temptation to try to draft something myself because
I want to see what you come up with.

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: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ian Jackson]

Guillem Jover writes ("Proposal: Reaffirm our commitment to support portability 
and multiple implementations"):
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations

I really like much of what you write in your proposal.

However, unfortunately, I don't think this is sufficient to resolve
the actual practical questions which keep coming up.

I think your proposal would work well as a preamble to many of the
other options, notably mine and Dmitry's.

I hesitate to add such a lot of text to my own proposal which is
already rather long.  I don't know what to do about this precisely.
I'm not sure whether it would make sense to have two versions of mine
with and without such a preamble ?

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: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Could you provide some more information about what your
> Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
> Russ> which has a pretty tiny list of dependencies and shouldn't
> Russ> require that systemd be running so far as I know.  Are you
> Russ> thinking of test suites that assume systemd is available?

> pkg-config for systemd is in systemd not libsystemd-dev

Oh, okay.  Also, I remembered some previous discussion that some libraries
end up with dependencies on systemd components for functionality.  Thanks,
I think I understand the issue now.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Could you provide some more information about what your
Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
Russ> which has a pretty tiny list of dependencies and shouldn't
Russ> require that systemd be running so far as I know.  Are you
Russ> thinking of test suites that assume systemd is available?

pkg-config for systemd is in systemd not libsystemd-dev

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Adam Borowski  writes:

> * request a list of non-systemd-hostile policies to be changed[4], initial
>   contents being:
>   • an unrelated package forcing an init switch on a straightforward apt
> invocation is RC-buggy (usually caused by an unthoughtful deps ordering)

For the record, I suspect we can get regular Policy consensus for this
rule, since having one's init system changed by installing some unrelated
package is clearly buggy.

>   • requesting a redundant .service file when an init script exists, without
> a good reason (doubles work and reduces test coverage)

Note that the next revision of Policy will recommend that all packages
that want to start a daemon have systemd units because the generator that
handles init scripts has various undesirable edge cases.  The systemd
behavior is generally better and more consistent if every service has a
unit file.

There were no objections during the Policy discussion process for this
change, for the record.

>   • allowing unrelated packages to be unbuildable when a specific daemon/etc
> is installed (ie, should B-Dep/library-Dep on not-yet-existing
> systemd-dev instead of systemd, but the problem is not restricted to
> systemd)

Could you provide some more information about what your concern is here?
libsystemd-dev depends only on libsystemd0, which has a pretty tiny list
of dependencies and shouldn't require that systemd be running so far as I
know.  Are you thinking of test suites that assume systemd is available?

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Adam Borowski]

[I purposefully abstained in participating in this discussion so far, as I
have quite strong views, and I hoped it will stay mostly civilised.  But
alas, last developments seem to fails these hopes.  Thus, let's help Guillem
improve his proposal.]

On Sat, Nov 30, 2019 at 02:11:56PM -0500, Sam Hartman wrote:
> > "Bdale" == Bdale Garbee  writes:
> Bdale> I find this really appealing as a higher-level statement of
> Bdale> values and intent, but unfortunately, I don't think the text
> Bdale> does anything to help resolve the problems that Sam set out
> Bdale> to try and tackle with this GR.
> 
> I concur with Bdale and Russ.  If this option wins I find that I
> wouldn't know how to go forward. [...]
> This issue gives no guidance on the sorts of issues that I and the
> policy editors are facing.  This option provides no guidance on how to
> approach the patterns of behavior that Ian and I have seen on our lists.

I agree.  There are statements but no clear guidance.  Thus, I'll list
problems in the current state of Debian in regard of systemd in particular:

* there's a lot of use cases where systemd fails[1].  This makes it unfit
  for being the sole init+rc of an universal operating system.
* patches fixing non-systemd regressions are routinely ignored[2]
* changes I view as done with spite, which bring no or negligible benefit to
  systemd yet large detriment to other rc systems[3]

On the other hand, you cannot require contributors to implement something
they don't care about nor have required hardware/etc for.  Thus, let's use
the approach already in place for porting to architectures:

1. no regressions (enforced by testing migration process)
2. porter patches are privileged:

# devref §5.10.2.2. source NMUs for porters
#
# [...] It also varies whether the architecture is a candidate for
# inclusion into the next stable release [...]
#
# If you are a porter doing an NMU for "unstable", the above guidelines
# for porting should be followed, with two variations. Firstly, the
# acceptable waiting period — the time between when the bug is submitted
# to the BTS and when it is OK to do an NMU — is seven days for porters
# working on the "unstable" distribution. This period can be shortened
# if the problem is critical and imposes hardship on the porting effort,
# at the discretion of the porter group.


I propose to extend these rules to more technologies, starting with init/rc
systems.  This will give us an actionable guidance Bdale and Russ requested.

Thus: Guillem, would you consider amending your proposal to:
* extend the above rules to a list of technologies, with the list's initial
  contents being:
  • sysv-rc, at severity equivalent to a release arch
  • openrc, at severity equivalent to a -ports arch
  • non-yet-packaged new rc systems, equivalent to an out-of-archive arch
  (sysv-rc and openrc share most of the efforts)
  Alternatively, you can say just "init scripts" without going into details.
* request a list of non-systemd-hostile policies to be changed[4], initial
  contents being:
  • an unrelated package forcing an init switch on a straightforward apt
invocation is RC-buggy (usually caused by an unthoughtful deps ordering)
  • requesting a redundant .service file when an init script exists, without
a good reason (doubles work and reduces test coverage)
  • allowing unrelated packages to be unbuildable when a specific daemon/etc
is installed (ie, should B-Dep/library-Dep on not-yet-existing
systemd-dev instead of systemd, but the problem is not restricted to
systemd)

(Some more terse wording would be nice.)


Meow!

[1]. Such as, it doesn't boot on my new main desktop.  Or, it breaks schemes
  that rely on mount --bind (which it randomly sometimes converts to --rbind
  after a raceable delay, sometimes it doesn't).  Or, it not only refuses to
  mount degraded btrfs RAID but even unmounts if mounted manually.  Or,
  sometimes causes data loss of mails sent from cronjobs/exiting daemons.
  My list is short only because for obvious reasons I avoid prolonged
  exposure to systemd.

[2]. The worst case being patches for compiling policykit both for systemd
  and consolekit (initially) then elogind (later), despite a tested
  solution being proposed and available since Jan 2018. This led to
  Buster being mostly unusable with a modern GUI.  Reactions we met with
  were: 1. stonewalling (no one but smcv graced us with a response), then
  2. stalling (long delays when responding to bugs), and 3. last-minute
  demand of large-scale rewrite (a request to make libelogind0
  ABI-compatible and replacing libsystemd0, instead of both being
  coinstallable).

[3]:
  * dependencies on "systemd | other" rather than "other | systemd"; this is
a no-op on a systemd system (installed by debootstrap before any
non-base packages) but causes apt to force an init+rc switch elsewhere
  * changing "service" (the rc-agnostic wrapper) to "systemctl"
  * (dubious due to 

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Paul Tagliamonte]

On Sat, Nov 30, 2019, 4:41 PM Bernd Zeimetz  wrote:

> Hi,
>
> > X<
> > Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> ... so how does this help the project? We are all wasting lots of time
> in discussing policy and if we want to support init and friends and if
> bugs are RC or not. You are basically saying that this needs to continue.
>
> I really hope that people vote this far below FD and I fail to
> understand why fellow developers actually second this.
>

I strongly agree. This proposal sounds nice as an aspirational set of
values to write proposals off of, but is deeply unhelpful in helping
resolve the rats nest we find ourselves in. I will be putting this option
below FD.

Paul

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
> 
> I'm thus proposing the following:

That is now on the website.


Kurt

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Bernd Zeimetz]

Hi,

> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations

... so how does this help the project? We are all wasting lots of time
in discussing policy and if we want to support init and friends and if
bugs are RC or not. You are basically saying that this needs to continue.

I really hope that people vote this far below FD and I fail to
understand why fellow developers actually second this.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 08:43:38PM +, Mike Gabriel wrote:
> Seconded.

Your message wasn't signed.


Kurt

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Alberto Gonzalez Iniesta]

On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Mike Gabriel]

Hi,

Am Samstag, 30. November 2019 schrieb Guillem Jover:
> Hi!
> 
> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection. It seems to me, that an
> init system is in principle just one of the many technologies we ship
> and integrate. But at least when it comes to systemd, choosing that in
> detriment to anything else, has a cascading effect of deciding on and
> closing doors on a wide range of technologies which have been declared
> incompatible by systemd upstream or by those other technologies.
> 
> For example the claims on "cross-distribution standards and
> cooperation", are pretty much restricted to GNU/Linux (glibc-based),
> not even say musl-based systems, or many other variations. systemd
> provides many nice features, but at the same time, as with any
> software, not all of them fit or are sufficient for all use cases or
> requirements, and people do want or have to use alternatives for many
> valid reasons.
> 
> 
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<
> 
> Thanks,
> Guillem
>

Seconded.

Mike
-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Sam Hartman]

> "Bdale" == Bdale Garbee  writes:

Bdale> Guillem Jover  writes:
>> I think the current GR is incorrectly framing the problem at
>> hand, as if it was just an init system selection.

Bdale> This resonates with me, but...

>> I'm thus proposing the following:

Bdale> I find this really appealing as a higher-level statement of
Bdale> values and intent, but unfortunately, I don't think the text
Bdale> does anything to help resolve the problems that Sam set out
Bdale> to try and tackle with this GR.

Bdale> I therefore find myself unwilling to second it, even though
Bdale> on some level I would really like to.

I concur with Bdale and Russ.  If this option wins I find that I
wouldn't know how to go forward.  I started this process because there
were issues coming before me as DPL that I didn't know how to address
because I didn't understand the direction of the project.
This issue gives no guidance on the sorts of issues that I and the
policy editors are facing.  This option provides no guidance on how to
approach the patterns of behavior that Ian and I have seen on our lists.

--Sam

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Bdale Garbee]

Guillem Jover  writes:

> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection.

This resonates with me, but...

> I'm thus proposing the following:

I find this really appealing as a higher-level statement of values and
intent, but unfortunately, I don't think the text does anything to help
resolve the problems that Sam set out to try and tackle with this GR.

I therefore find myself unwilling to second it, even though on some
level I would really like to.

Bdale


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Guillem Jover  writes:

> I'm thus proposing the following:

> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations

Should this be on the ballot, I will vote it below FD because it provides
essentially no guidance to how to resolve the concrete Policy problems
that are my primary concern in this GR.

This resolution would make Policy's job even more difficult than it
already is.  It says a lot of wonderful-sounding things, but it makes all
of the practical and community problems facing Debian even worse by
refusing to provide any clarity.  It's essentially equivalent to just
voting for Further Discussion, except that it adds a very vague position
statement for all sides to beat each other over the head with ("you're not
welcoming the integration of diverse technologies" vs. "you're not willing
to put in the effort required").

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Steve Kostecke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guillem Jover said:

>X<
>Title: Reaffirm our commitment to support portability and multiple 
>implementations

>The Debian project reaffirms its commitment to be the glue that binds
>and integrates different software that provides similar or equivalent
>functionality, with their various users, be them humans or other software,
>which is one of the core defining traits of a distribution.
>
>We consider portability to different hardware platforms and software
>stacks an important aspect of the work we do as a distribution, which
>makes software architecturally better, more robust and more future-proof.
>
>We acknowledge that different upstream projects have different views on
>software development, use cases, portability and technology in general.
>And that users of these projects weight tradeoffs differently, and have
>at the same time different and valid requirements and/or needs fulfilled
>by these diverse views.
>
>Following our historic tradition, we will welcome the integration of
>these diverse technologies which might sometimes have conflicting
>world-views, to allow them to coexist in harmony within our distribution,
>by reconciling these conflicts via technical means, as long as there
>are people willing to put in the effort.
>
>This enables us to keep serving a wide range of usages of our distribution
>(some of which might be even unforeseen by us). From servers, to desktops
>or deeply embedded; from general purpose to very specifically tailored
>usages. Be those projects hardware related or software based, libraries,
>daemons, entire desktop environments, or other parts of the software
>stack.
>X<

Seconded

- -- 
Steve Kostecke 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEGH2sJVLoH0wvM1tGQgpClenb3bwFAl3itPEACgkQQgpClenb
3bz2Ow//X3604SG61vxZpW1rgInfqKiarDMmCiHPBno/ZLecPGecvdhrzGPlfT3F
O3BZ2UPdhrkhrz1Bhl/ElRV+032Nhu1ZF5j82N1Lm5YiN6HmWU9RyDhGLxrCVCSK
p4lPOrDx0Eb52c3lIo2R1tpNATs6cG5JfuxyR4nYvuoCnRZyROUhnwihurjdmL2r
mCxwQHdZ/DV90H+ceqKnTqbeqgZthzBL0jZ+3bhon4EctUDK/HLyGmyChrkrE2Fu
n+IzmnnxeB8PSR3SqqXvmYb+LYz9TVrlrj/xO7IHCanADCMghhcPzZ6l+l3DvU9/
WBdGwYzwP3chNymt2tSkD0ogdgyAm4lbmpszr26wfXF+46+9cZhuOHiAx7asmmaz
3GqVWioj3gXTAEDiIkXnGtbA99CIpVhPEtA7fBwU+mtRH2isYBzQxWSpVo4Nbk3J
3rkVKv+sb+Oso/bzdF4C0zEAuglpu7eVDnyFN1Mp5z4U+iEyNWHHYwynJ0DWvGt0
//IJSb15QB980ErD9VstHSxuky54fBDc2hzb5iqgxM9HSrWFCg4NHqtOkgJEi3lc
2PYMwhNDXg6oi4MfRFAEjy7vt9TeS4HzyGOAieP2HEGO+rCjwbu+9e/JqQmT1aMt
kou751bqIkZAIbfvLxXzKW0vJZvUsGW9Bq7t3jtI+xBrUgVj1Dk=
=Gd1A
-END PGP SIGNATURE-

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Mathias Behrle]

* Guillem Jover: " Proposal: Reaffirm our commitment to support portability and
  multiple implementations" (Sat, 30 Nov 2019 18:46:27 +0100):


> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

Cheers
Mathias

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpppRCShTFTa.pgp
Description: Digitale Signatur von OpenPGP

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ricardo Mones]

On Sat, 30 Nov 2019 18:46:27 +0100
Guillem Jover  wrote:
[...]
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other
> software, which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more
> future-proof.
> 
> We acknowledge that different upstream projects have different views
> on software development, use cases, portability and technology in
> general.  And that users of these projects weight tradeoffs
> differently, and have at the same time different and valid
> requirements and/or needs fulfilled by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our
> distribution, by reconciling these conflicts via technical means, as
> long as there are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our
> distribution (some of which might be even unforeseen by us). From
> servers, to desktops or deeply embedded; from general purpose to very
> specifically tailored usages. Be those projects hardware related or
> software based, libraries, daemons, entire desktop environments, or
> other parts of the software stack.
> X<

Seconded.

best regards,
-- 
  Ricardo Mones 
  ~
  bash: ./signature: No such file or directory  /bin/bash



signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Guilhem Moulin]

On Sat, 30 Nov 2019 at 18:46:27 +0100, Guillem Jover wrote:
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

-- 
Guilhem.


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Jonas Smedegaard]

Quoting Guillem Jover (2019-11-30 18:46:27)
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[gregor herrmann]

On Sat, 30 Nov 2019 18:46:27 +0100, Guillem Jover wrote:

> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.


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: Bob Dylan: I Want You


signature.asc
Description: Digital Signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

On 30.11.19 18:46, Guillem Jover wrote:

> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

   Simon



signature.asc
Description: OpenPGP digital signature

Proposal: Reaffirm our commitment to support portability and multiple implementations

[Guillem Jover]

Hi!

I think the current GR is incorrectly framing the problem at hand,
as if it was just an init system selection. It seems to me, that an
init system is in principle just one of the many technologies we ship
and integrate. But at least when it comes to systemd, choosing that in
detriment to anything else, has a cascading effect of deciding on and
closing doors on a wide range of technologies which have been declared
incompatible by systemd upstream or by those other technologies.

For example the claims on "cross-distribution standards and
cooperation", are pretty much restricted to GNU/Linux (glibc-based),
not even say musl-based systems, or many other variations. systemd
provides many nice features, but at the same time, as with any
software, not all of them fit or are sufficient for all use cases or
requirements, and people do want or have to use alternatives for many
valid reasons.


I'm thus proposing the following:

X<
Title: Reaffirm our commitment to support portability and multiple 
implementations

The Debian project reaffirms its commitment to be the glue that binds
and integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.

We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.

We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight tradeoffs differently, and have
at the same time different and valid requirements and/or needs fulfilled
by these diverse views.

Following our historic tradition, we will welcome the integration of
these diverse technologies which might sometimes have conflicting
world-views, to allow them to coexist in harmony within our distribution,
by reconciling these conflicts via technical means, as long as there
are people willing to put in the effort.

This enables us to keep serving a wide range of usages of our distribution
(some of which might be even unforeseen by us). From servers, to desktops
or deeply embedded; from general purpose to very specifically tailored
usages. Be those projects hardware related or software based, libraries,
daemons, entire desktop environments, or other parts of the software
stack.
X<

Thanks,
Guillem


signature.asc
Description: PGP signature