On Fri, Nov 15, 2019 at 01:10:58AM -0500, Brian Gupta wrote:
> Do you think it's ok in any case to remove init scripts. Let's say an
> upstream stops maintaining init scripts,
In my experience init scripts can only be written for Debian, not
"maintained upstream".
--
WBR, wRAR
signature.asc
De
On Thu, Nov 14, 2019 at 7:51 PM Dmitry Bogatov wrote:
>
> [2019-11-14 17:15] Ian Jackson
> > Dmitry Bogatov writes ("Draft text on Init Systems GR"):
> > > Choice 1: Affirm Init Diversity
> > >
> > > Being able to run Debian systems with init systems other than
> > > systemd continue
On November 15, 2019 3:26:31 AM UTC, Russ Allbery wrote:
>Scott Kitterman writes:
>
>> This option makes multiple references to RC and non-RC bugs based on
>> actions of the policy editors.
>
>> It's my understanding that determining if a bug is RC or not is a
>> Release Team function, not the
Scott Kitterman writes:
> This option makes multiple references to RC and non-RC bugs based on
> actions of the policy editors.
> It's my understanding that determining if a bug is RC or not is a
> Release Team function, not the policy editors.
> Would it be better to use something like 'severe
On November 14, 2019 8:08:28 PM UTC, Sam Hartman wrote:
>
>
>I'd like to propose the following resolution.
>
>Seconds are not required, but it would be valuable to get confirmation
>that the three choices contained in this proposal are worth having on
>the ballot.
>So, rather than seconding the
Brian Gupta writes:
> On Thu, Nov 14, 2019 at 9:13 PM Russ Allbery wrote:
>> Are you specifically looking for an option that says that packages that
>> support systemd are required to support sysvinit and that it's an RC
>> bug if they don't?
> Yes. That was my understanding of the tortured con
On Thu, Nov 14, 2019 at 9:13 PM Russ Allbery wrote:
> Brian Gupta writes:
>
> > I would like to see an additional option to leave current policy
> > unchanged. Obviously if I am alone in wanting this option, please
> > disregardt.
>
> What does that mean to you? I ask because Policy is a littl
Am Do., 14. Nov. 2019 um 21:24 Uhr schrieb Sam Hartman :
>
> I'd like to propose the following resolution.
>
> Seconds are not required, but it would be valuable to get confirmation
> that the three choices contained in this proposal are worth having on
> the ballot.
> So, rather than seconding the
Wouter Verhelst writes:
> On Thu, Nov 14, 2019 at 06:36:53PM +, Ian Jackson wrote:
>> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>>
>> * Failing to support non-systemd systems when such support is
>>available, or offered in the form of patches (or packages),
>>*should* be
Brian Gupta writes:
> I would like to see an additional option to leave current policy
> unchanged. Obviously if I am alone in wanting this option, please
> disregardt.
What does that mean to you? I ask because Policy is a little incoherent
and a lot incomplete.
Are you specifically looking f
Ian Jackson writes:
> Here is my proposal. It is unfortunately quite long. The reason is
> that I am trying to address the dysfuncdtional patterns I have seen over
> the past few years, and give specific remedies.
I wish that a GR had the moral suasion that would get everyone to be
excellent t
Dmitry Bogatov writes:
> Choice: Affirm Init Diversity
> 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 designed
> by upstream to work
On Thu, Nov 14, 2019 at 7:09 PM Russ Allbery wrote:
> Sam Hartman writes:
>
> > I'd like to propose the following resolution.
>
> > Seconds are not required, but it would be valuable to get confirmation
> > that the three choices contained in this proposal are worth having on
> > the ballot. So
[2019-11-14 17:15] Ian Jackson
> Dmitry Bogatov writes ("Draft text on Init Systems GR"):
> > Choice 1: Affirm Init Diversity
> >
> > Being able to run Debian systems with init systems other than
> > systemd continues to be value for the project. Package not
> > working with
Choice: Affirm Init Diversity
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 designed
by upstream to work exclusively with system
Sam Hartman writes:
> I'd like to propose the following resolution.
> Seconds are not required, but it would be valuable to get confirmation
> that the three choices contained in this proposal are worth having on
> the ballot. So, rather than seconding the proposal it would be useful
> if peopl
The three options of your proposal are worthwhile to have on the ballot.
Cheers
Luk
I'd like to propose the following resolution.
Seconds are not required, but it would be valuable to get confirmation
that the three choices contained in this proposal are worth having on
the ballot.
So, rather than seconding the proposal it would be useful if people
would ack choices here they'd
Ian, first, thanks for a really great and constructive proposal.
I'm assuming you plan to propose this as an amendment and get seconds.
There's one area where I'm hoping you can come up with different
wording, because at least for me, your current wording fails at being
excellent to each other.
On Thu, Nov 14, 2019 at 06:36:53PM +, Ian Jackson wrote:
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>
> * Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bu
Sam Hartman writes ("[draft] Draft text on Init Systems GR"):
> This is a draft GR. I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.
Here is my proposal. It is unfortunately quite long. The reason is
that I am trying to address th
Holger Levsen writes ("adding more topics to this GR (Re: [draft] Draft text on
Init Systems GR)"):
> On Thu, Nov 14, 2019 at 05:31:19PM +, Ian Jackson wrote:
> > Issue 4. Hateful stuff on our lists etc.
> >
> > I have tried to capture what kinds of statements are the key problem
> > here.
On Thu, Nov 14, 2019 at 04:16:58PM +, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> > You can formally propose a GR today, and I recommend you do -- otherwise
> > we end up discussing things before the discussion period, and then you
> > need to si
On Mon, Nov 11, 2019 at 08:58:52AM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst writes:
> Wouter> Oh, right. Okay. I suppose that makes sense; the nbd-client
> Wouter> init script hasn't been touched since I wrote the nbd-client
> Wouter> systemd unit, and so I can't r
On Thu, Nov 14, 2019 at 05:31:19PM +, Ian Jackson wrote:
> Issue 4. Hateful stuff on our lists etc.
>
> I have tried to capture what kinds of statements are the key problem
> here. I think we need to clearly tell our listmasters etc. what we
> expect, since enforcement action they take needs
Sam Hartman writes ("[draft] Draft text on Init Systems GR"):
> This is a draft GR. I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.
I don't think these options really answer the key questions clearly.
I am going to propose a draft
Dmitry Bogatov writes ("Draft text on Init Systems GR"):
> So, here is my rewording, much simplier and shorter.
>
> Choice 1: Affirm Init Diversity
>
> Being able to run Debian systems with init systems other than
> systemd continues to be value for the project. Package no
Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> You can formally propose a GR today, and I recommend you do -- otherwise
> we end up discussing things before the discussion period, and then you
> need to sit and wait at least seven days during the *actual* discussion
> perio
I'm using the language of amendments and stuff even though I realize
this is not formally correct.
hi.
My current plan to move forward based on discussion here is:
* Update choice 1 to accept an amendment proposed by Martin:
Correct an ambiguous sentence to say:
> a package having a service
29 matches
Mail list logo