Ansgar writes:
> It's mostly that it pushes systemd preference a bit more than my
> preference, mostly because the short text also reads "Focus on systemd
> for [...] other facilities", but I have no preference for systemd over
> other implementations for "other facilities".
> I see value in cro
Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:
>
>>> Unless the project or relevant parties have agreed otherwise, systemd
>>> facilities, where they exist and are stable and supported by the
>>> systemd maintainers, should be preferred over Debian-s
Ansgar writes:
> On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:
>> Unless the project or relevant parties have agreed otherwise, systemd
>> facilities, where they exist and are stable and supported by the
>> systemd maintainers, should be preferred over Debian-specific ways of
>> solving t
Bernd Zeimetz writes:
> On 11/15/19 3:06 PM, Ian Jackson wrote:
>> The problem with even your option B is that there is no effective route
>> for non-systemd systems to "catch up" as you put it.
> For some systemd Features there is no sane route to implement them for a
> non-systemd system. Espe
On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:
> Choice hartmans1: Affirm Init Diversity
[...]
> Init scripts are the lowest common denominator across all init
> systems.
I think naming options "Init diversity" isn't really expressive: if
current options "A" and "E" are called "Affirm Init
On 11/19/19 9:00 PM, Thomas Goirand wrote:
> I agree with Holger that it's probably better to leave the amount of
> time undefined, and see what happens on a case by case basis.
please let's not find a way to delay the next release forever.
--
Bernd ZeimetzDebian
On 11/15/19 3:06 PM, Ian Jackson wrote:
> The problem with even your option B is that there is no effective
> route for non-systemd systems to "catch up" as you put it.
For some systemd Features there is no sane route to implement them for a
non-systemd system. Especially all the security featu
On 11/15/19 1:12 PM, Ian Jackson wrote:
>> Choice hartmans3: Focus on systemd for Init System and Other Facilities
>
> If this option wins I will significantly reduce my involvement in
> Debian. I think there are probably other contributors for whom this
> is the case. I imagine that there ar
Kurt Roeckx writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> That whole part could really use some fixing. The more you read
> it, the more you think it says something else.
Yes. I'm sorry about that. I have been thinking about these
ma
On Wed, Nov 20, 2019 at 08:54:55AM -0800, Russ Allbery wrote:
> Sam Hartman writes:
>
> > To clarify, my understanding is that the discussion period started
> > November 16.
> > So, we're talking about a minimum discussion period expiring on
> > November 30.
>
> Your acceptance of my amendment
On Wed, Nov 20, 2019 at 09:58:51AM -0500, Sam Hartman wrote:
> > "Ian" == Ian Jackson writes:
>
> Ian> Sam Hartman writes ("Proposal: General Resolution on Init
> Ian> Systems and systemd Facilities"):
> >> Timeline: I think that two weeks for discussion of this GR seems
> >>
On Wed, Nov 20, 2019 at 01:07:44PM +, Ian Jackson wrote:
>
> I would note that as the proposer of an option with enough seconds, I
> can also call for a vote when the minimum discussion period has
> elapsed. You can increase the minimum discussion period, but only to
> 3 weeks. IMO it would
> "Russ" == Russ Allbery writes:
>> Sam Hartman writes:
>>> It's my intent today or tomorrow to accept the amendment and to
>>> update the discussion period to continue to expire on November
>>> 30.
Russ> Sam said that he'd be willing to delay if needed if an
Russ> a
On Wed, Nov 20, 2019 at 09:37:59PM +, Holger Levsen wrote:
> ah! Now I see that this is ment differently than it was proposed.
s#it#how I understood it#
--
cheers,
Holger
---
holger@(debi
Holger Levsen writes:
> What I missed that this delay (of 6/12 month) is a delay for *-policy*
> about describing/defining such a feature. I thought it ment to prohibit
> people from using such new features.
It's a delay from the point at which Policy standardizes using systemd
services instead
On Tue, Nov 19, 2019 at 01:24:24PM -0800, Russ Allbery wrote:
> > I agree with Holger that it's probably better to leave the amount of
> > time undefined, and see what happens on a case by case basis.
> If we're going to expect there to be a transition period, I would prefer
> the time be defined,
Ian Jackson writes:
> Sam Hartman writes:
>> It's my intent today or tomorrow to accept the amendment and to update
>> the discussion period to continue to expire on November 30.
> I think a decision to shorten the minimum discussion period from the
> constitutional default would be highly inapp
Sam Hartman writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> It's my intent today or tomorrow to accept the amendment and to update
> the discussion period to continue to expire on November 30.
I think a decision to shorten the minimum d
Sam Hartman writes:
> I did?
> I thought I told you I would accept the amendment.
> It's my intent today or tomorrow to accept the amendment and to update
> the discussion period to continue to expire on November 30.
Oh, I see. Your message to debian-vote specifically was:
| I am in fact going
> "Russ" == Russ Allbery writes:
Russ> Sam Hartman writes:
>> To clarify, my understanding is that the discussion period
>> started November 16. So, we're talking about a minimum
>> discussion period expiring on November 30.
Russ> Your acceptance of my amendment reset t
Russ Allbery writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> (I also think this is a bug in the constitution; it means that a rejected
> but seconded amendment can go on the ballot immediately before the vote
> with no time for further
Sam Hartman writes:
> To clarify, my understanding is that the discussion period started
> November 16.
> So, we're talking about a minimum discussion period expiring on
> November 30.
Your acceptance of my amendment reset the clock, at least by my reading of
the constitution. That happened on
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Proposal: General Resolution on Init
Ian> Systems and systemd Facilities"):
>> Timeline: I think that two weeks for discussion of this GR seems
>> about right based on what's happened in the last week. The
>> consti
Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd
Facilities"):
> Timeline: I think that two weeks for discussion of this GR seems about
> right based on what's happened in the last week. The constitution
> allows the DPL to change the disc
Ian Jackson writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> Of course if the (re)implementation(s) of the (new) interface are
> complete before the time is up, there would be no reason to continue
> to delay, and blessing imm
Russ Allbery writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> If we're going to expect there to be a transition period, I would prefer
> the time be defined, rather than left for case-by-case argument. If folks
> would prefer that we
Thomas Goirand writes:
> I agree with Holger that it's probably better to leave the amount of
> time undefined, and see what happens on a case by case basis.
If we're going to expect there to be a transition period, I would prefer
the time be defined, rather than left for case-by-case argument.
On 11/18/19 10:43 AM, Holger Levsen wrote:
> On Sat, Nov 16, 2019 at 06:12:49PM +, Ian Jackson wrote:
>> Holger Levsen writes ("Re: Proposal: General Resolution on Init Systems and
>> systemd Facilities"):
>>> On Fri, Nov 15, 2019 at 01:22:26PM -0700, Sean Wh
On Sat, Nov 16, 2019 at 06:12:49PM +, Ian Jackson wrote:
> 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 mont
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 i
Simon Richter writes:
> GNOME and systemd coordinate among themselves mostly, adding features as
> required for their use cases. As long as no one outside these particular
> ecosystems uses these features, we can just step aside and wait for
> wider adoption.
> The majority of packages we have i
Hi,
On Fri, Nov 15, 2019 at 10:03:35AM -0800, Russ Allbery wrote:
> My personal preference is for the project to either decide that we're
> going to use systemd facilities by default and sysvinit is going to break,
> or to decide that we're going to require standardized interfaces with the
> opti
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 features, we
> could repeal this GR.
I'm pondering an amendment to copy this option but without the 6 mo
Hello,
On Fri 15 Nov 2019 at 10:03AM -08, Russ Allbery wrote:
> I think I would rather have the clear path forward your proposal lays out,
> with a 6-12 month delay, than to have my options B or C that set up Policy
> discussions for each new feature while maintainers move forward in advance
> of
Ian Jackson writes:
> My proposal provides a clear escalation path, and clear guidance to the
> TC. No useful new facilities will be blocked forever.
> It is true that adoption of new facilities does in my proposal depend on
> some discussion. But indeed that is reasonable. There aren't (or
>
Sam Hartman writes ("Re: Proposal: General Resolution on Init Systems and
systemd Facilities"):
> Under Russ's option B and C, which I capture in my proposal, non-systemd
> users get degraded behavior until we agree on an approach and
> standardize it.
The reason this
On Fri, 2019-11-15 at 07:39 -0500, Sam Hartman wrote:
> Your proposal blocks people from using the new facility until that
> discussion happens.
It also allows non-systemd to block progress for 6-12 months even after
discussion and at any later time for any enhancement (new feature) of
any facilit
> "Ian" == Ian Jackson writes:
Ian> For example, suppose upstream ship a timer unit. A Debian
Ian> contributor wants to supply a patch to make the package use
Ian> cron. You might very well want to use cron even with systemd;
Ian> some people prefer cron's featureset. How
Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd
Facilities"):
> Choice hartmans1: Affirm Init Diversity
I have read through these options and I find them unsatisfactory in
their treatment of what I'm calling `non-init-related declarative
system
Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd
Facilities"):
> Timeline:
Please can we have more time.
Ian.
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
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
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
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
51 matches
Mail list logo
