Sam Hartman writes:
> I have high confidence that a decision in this space will give the
> policy editors the tools they need to break the consensus deadlock
> without having to resort to overriding them or setting policy as a
> project. That is, in this case, a non-binding statement that we kno
> "Kurt" == Kurt Roeckx writes:
Kurt> On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote:
>>
>> The secretary requested that I have each choice be
>> self-contained. So I'm folding the header into each choice.
>>
>> The line of dashes separates each choice
Hello,
On Sat 16 Nov 2019 at 06:18PM +00, Ian Jackson wrote:
> I hereby formally propose the following amendent (for my reference,
> 42471fd). Replace the entire text, with the text below.
I too second the below quoted amendment. Thank you, Ian.
> - -8<-
>
> Title: Support non-systemd systems
Kurt Roeckx writes:
> Even though it always says it's using 4.1.5, I have a hard time seeing
> why I shouldn't also put them under 4.1.4 (and 4.1.3). As currently
> written, I will most likely interprete them as using the power of 4.1.4,
> and so require a 2:1 majority.
Here's my reasoning for w
On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote:
>
> Choice hartmans1: Affirm Init Diversity
>
> Using its power under Constitution section 4.1 (5), the project issues
> the following statement describing our current position on Init
> systems, Init system diversity, and the use of sy
I propose the following amendment to clarify the division of
responsibilities problem that Scott noticed. I'm not seeking seconds
since I suspect Sam will accept this amendment.
Below each quoted sentence is the proposed replacement.
(The terminology in use in Policy is incredibly awkward, and t
Russ Allbery writes:
> Ansgar writes:
>> So three hypothetical examples:
>> - a hypothetical GNOME version that requires a build-time choice
>>between `systemd --user` and the traditional session implementation;
>>(GNOME can use `systemd --user` already[1], but it's not a build-time
>>
Ian Jackson writes:
> I hereby formally propose the following amendent (for my reference,
> 42471fd). Replace the entire text, with the text below.
I second the below quoted amendment.
> -8<-
> Title: Support non-systemd systems, without blocking progress
> PRINCIPLES
> 1. We wish to contin
Ian, if you have a moment, could you also weigh in here to confirm that
I've understood the intent of your proposal correctly?
Ansgar writes:
> So three hypothetical examples:
> - a hypothetical GNOME version that requires a build-time choice
>between `systemd --user` and the traditional s
On Sat, Nov 16, 2019 at 11:08:36PM +, Scott Kitterman wrote:
> As I've mentioned before, these need to be framed in terms of policy, not
> RCness.
Note that we also have delegated policy editors:
https://lists.debian.org/debian-devel-announce/2018/08/msg2.html
Kurt
On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote:
>
> The secretary requested that I have each choice be self-contained.
> So I'm folding the header into each choice.
>
> The line of dashes separates each choice.
> I formally propose these general resolution options.
Can you please cl
On November 16, 2019 10:50:59 PM UTC, Kurt Roeckx wrote:
>On Sat, Nov 16, 2019 at 05:40:10PM +, Dmitry Bogatov wrote:
>>
>> [2019-11-15 11:52] Ian Jackson
>> > Dmitry, I suggest instead, this change to your original text:
>>
>> Being able to run Debian systems with init systems othe
On Sat, Nov 16, 2019 at 05:40:10PM +, Dmitry Bogatov wrote:
>
> [2019-11-15 11:52] Ian Jackson
> > Dmitry, I suggest instead, this change to your original text:
>
> Being able to run Debian systems with init systems other than
> systemd continues to be value for the project. Pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sam Hartman writes ("Re-Proposing: General Resolution on Init Systems and
systemd"):
> The line of dashes separates each choice.
> I formally propose these general resolution options.
I hereby formally propose the following amendent (for my referen
Holger Levsen writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> On Fri, Nov 15, 2019 at 01:22:26PM -0700, Sean Whitton wrote:
> > If we found that the six month delay was repeatedly expiring with no
> > serious attempts at non-systemd implementations of the new
[2019-11-15 11:52] Ian Jackson
> Dmitry, I suggest instead, this change to your original text:
Being able to run Debian systems with init systems other than
systemd continues to be value for the project. Package not
working with pid1 != systemd is RC bug, unless it was d
[2019-11-15 01:10] Brian Gupta
> I guess my question is what does it mean to say "designed by upstream
> to work exclusively with systemd"? Is that ambiguous, or clear to
> everyone? I think we're going to hit grey areas, where upstreams may
> only test with systemd, but that it can be made to
[2019-11-14 18:17] Russ Allbery
> >> The implication I would take as Policy editor from this option winning
> >> is that any systemd service that is not supported by (all?) other init
> >> systems in Debian must not be used, except in packages whose upstreams
> >> only support systemd. Packages
The secretary requested that I have each choice be self-contained.
So I'm folding the header into each choice.
The line of dashes separates each choice.
I formally propose these general resolution options.
Version 1385c4e4ba56da
Choice hartmans1: Affir
19 matches
Mail list logo
