On 11/19/19 7:29 PM, Ian Jackson wrote:
> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson writes:
>>> Please do formally propose it and I will give my formal blessing to it.
>
>> If I understand the process correctly,
On 11/17/19 9:00 PM, Russ Allbery wrote:
> Joshua Hudson writes:
>
>> The debate on systemd often turns into systemd vs. sysvinit because
>> sysvinit is the working alternative right now. Unfortunately, this is a
>> poor way to frame the debate. The reality is sytemd unit files are a
>> really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ian Jackson writes:
> > Please do formally propose it and I will give my formal blessing to it.
>
> If I understand the process correctly, that looks
On Mon, Nov 18, 2019 at 05:37:46PM -0700, Sean Whitton wrote:
> Hello,
>
> On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
>
> > Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> >> Ian Jackson writes:
> >> > + (wi
Hi,
On 2019/11/19 02:37, Sean Whitton wrote:
> Hello,
>
> On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
>
>> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>>> Ian Jackson writes:
>>>> + (with no substantial effect
Ian Jackson writes:
> Please do formally propose it and I will give my formal blessing to it.
If I understand the process correctly, that looks like this:
I propose that point 7 of Iam's seconded proposal be replaced with point 7
as shown here:
> 7. Failing to support non-systemd systems when
Hello,
On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson writes:
>> > + (with no substantial effect on systemd installations)
>>
>> Yes, that looks great to me
On Mon, Nov 18, 2019 at 12:57:04PM +, Ian Jackson wrote:
> It is not clear to me who can "accept" it - would that me be as the
> proposer of this version, or Sam as the original proposer ? Perhaps
> Kurt's life would be made easier if Sam would, at the appropriate
> point, indicate his
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ian Jackson writes:
> > + (with no substantial effect on systemd installations)
>
> Yes, that looks great to me.
I have folded it in and the result is below.
> Let me know if it would be helpful
Ian Jackson writes:
> You have got my intent right. How about this as a suggested fix
>patches which contribute support for other init
>systems
> + (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'
> leaving changes which *do*
On Sun, Nov 17, 2019 at 11:24:44AM -0800, Joshua Hudson wrote:
> The debate on systemd often turns into systemd vs. sysvinit because sysvinit
> is
> the working alternative right now. Unfortunately, this is a poor way
> to frame the
> debate. The reality is sytemd unit files are a really good
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ah, I think this is making me realize there's a somewhat odd conflict
> between point 7 and point 8 that I didn't notice. The criteria in point 7
> is stronger (the contributed support does not introd
On 11/15/19 6:49 PM, Russ Allbery wrote:
> 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.
>
> After sleeping on this, I
Joshua Hudson writes:
> The debate on systemd often turns into systemd vs. sysvinit because
> sysvinit is the working alternative right now. Unfortunately, this is a
> poor way to frame the debate. The reality is sytemd unit files are a
> really good idea, but systemd's hardware detection leaves
The debate on systemd often turns into systemd vs. sysvinit because sysvinit is
the working alternative right now. Unfortunately, this is a poor way
to frame the
debate. The reality is sytemd unit files are a really good idea, but systemd's
hardware detection leaves much to be desired.
You're
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, 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
Russ Allbery writes:
> Ansgar writes:
>> Note that this would also block updating upstream packages to new
>> releases, possibly delaying development for a long time. I don't think
>> we need much slower development cycles.
>
> I'm not sure why you think this is the case. Could you explain more
Ansgar writes:
> It doesn't have to have the same complexity as logind or udev. Keep in
> mind that Policy doesn't even document init scripts properly: in
> particular LSB comment headers and such are also missing. We weren't
> able to document that in Policy for a long time and other
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> 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 ye
Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
>>> As with Dmitry's proposal, I'm not seconding this because it's not my
>>> own first choice, but I would vote this above further discussion and
>>> I'm satisfied that it's clear about the Policy
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> I was assuming that logind was out of scope (as was udev) because both
> have already been adopted by Debian, so this isn't the same situation that
> Ian's proposal is describing. The remaining facilities th
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.
After sleeping on this, I am going to second this proposal. I think it's
Ansgar writes:
> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
>> As with Dmitry's proposal, I'm not seconding this because it's not my
>> own first choice, but I would vote this above further discussion and
>> I'm satisfied that it's clear about the Policy implications.
> Do you think
Hi Russ,
On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
> As with Dmitry's proposal, I'm not seconding this because it's not my own
> first choice, but I would vote this above further discussion and I'm
> satisfied that it's clear about the Policy implications.
Do you think it is
On Fri, 2019-11-15 at 07:11 -0500, Sam Hartman wrote:
> Ian> * Declining to accept init scripts, or arguing against the
> Ian> inclusion of init scripts, on the grounds that they should
> be
> Ian> properly tested by the maintainer and the author doesn't
> Ian> consider testing
> "Ian" == Ian Jackson writes:
Ian> The patterns I am trying to address with this are things like:
Ian> * Vague RC bug reports against pieces of the non-systemd
Ian> ecosystem, which do not actually describe a particular bug, or
Ian> an approach acceptable to the
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> I wish that a GR had the moral suasion that would get everyone to be
> excellent to each other, but I'm somewhat dubious. I'm not a huge fan of
> trying to tackle that in the same GR as the technical questio
Sam Hartman writes ("Re: [draft] Draft text on Init Systems GR"):
> [Ian's proposal]
> >It is also for maintainers of
> > non-default init systems, and the surrounding community, to decide
> > what level of compromised functionality is acceptable to
Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Wouter Verhelst writes:
> > The problem with this is that it, essentially, promotes drive-by
> > patching: someone would like to use a program, but it doesn't come with
> > support for their ini
On Thu, Nov 14, 2019 at 06:32:32PM -0800, Russ Allbery wrote:
> Wouter Verhelst writes:
> > I think a better solution is to accept that some maintainers simply
> > won't have the time or inclination to maintain support for non-default
> > init systems, and that such init scripts (or whatever)
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*
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
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
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 t
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 statemen
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 peri
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
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
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
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
Ansgar [2019-11-11 18:41 +0100]:
> Mike Gabriel writes:
> > I agree with that and at the same time think that we (Debian) should
> > do our best at being universal (that's what the upcoming vote is
> > about).
>
> How so?
>
> Debian doesn't support multiple libc implementations. So it's already
Bernd Zeimetz writes:
> On 2019-11-12 18:56, Russ Allbery wrote:
>> Including options in a GR that no one supports is a waste of everyone's
>> time and mental energy.
> How do you know that no one supports that?
I'm not. That was the point of the rest of my message, which describes
the
On Wed, Nov 13, 2019 at 02:59:51PM +0100, Matthias Klumpp wrote:
> Exactly this. I think I would definitely second a "focus on systemd"
> amendment which makes packages support systemd as a priority, but
> doesn't force out sysvinit or any other init system from the archive.
> I think there's a
Am Mi., 13. Nov. 2019 um 11:55 Uhr schrieb Holger Levsen
:
>
> On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote:
> > Choice 4: systemd without Diversity at all
>
> as said before, I dislike the 'without diversity' framing and think it's
> wrong, misleading and insulting. So
On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote:
> Choice 4: systemd without Diversity at all
as said before, I dislike the 'without diversity' framing and think it's
wrong, misleading and insulting. So I'd rather propose 'focus our efforts
on systemd' or 'systemd and
On Wed, Nov 13, 2019 at 11:46:27AM +0100, Bernd Zeimetz wrote:
> > > I think that one choice is missing here. Could you please include
> > > something like this, just to see how many people are THAT radical?
> > > P.S. myself, I wouldn't vote for this even if I had a vote.
> >
> > > Choice 4:
On 2019-11-12 18:56, Russ Allbery wrote:
"Alexander E. Patrakov" writes:
I think that one choice is missing here. Could you please include
something like this, just to see how many people are THAT radical?
P.S. myself, I wouldn't vote for this even if I had a vote.
Choice 4: systemd
[Disclaimer: I am not a Debian Developer so have no formal power to
propose anything.]
Sam Hartman wrote:
Choice 1: Affirm Init Diversity
Choice 2: systemd but we Support Exploring Alternatives
Choice 3: systemd without Diversity as a Priority
I think that one choice is missing here. Could
Mike Gabriel writes:
> On Sa 09 Nov 2019 23:57:08 CET, Matthias Klumpp wrote:
>> The one thing I am against though is the non-Linux ports holding back
>> innovation and experimentation on the Linux ports. If we go with the
>> lowest common denominator, we can't realistically move forward, ever.
>
Hi Matthias,
On Sa 09 Nov 2019 23:57:08 CET, Matthias Klumpp wrote:
Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel
:
[...]
Isn't as side-question that is on the table with this GR: what about
the future of non-Linux variants of Debian. If systemd becomes _the_
init system of focus in
> "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 really guarantee that it will
Wouter> work very well anymore.
This is a reply to multiple messages.
I know it's long, I don't see a way to avoid that.
Search for lines of equal signs (=) to split issues I'm replying to.
Working with Downstreams
So, a couple of people have commented on the commitment to work with
downstreams in
Hi,
On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote:
> > Yes, that would be my desired outcome: an affirmation that Debian wants to
> > be "universal". This has been our greatest strength for years.
> Its a strength that wasted an enormous amount of ressources. See
> kfreebsd
On 11/9/19 11:24 PM, Simon Richter wrote:
> Yes, that would be my desired outcome: an affirmation that Debian wants to
> be "universal". This has been our greatest strength for years.
Its a strength that wasted an enormous amount of ressources. See
kfreebsd (which was actually really nice!)
Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel
:
> [...]
> Isn't as side-question that is on the table with this GR: what about
> the future of non-Linux variants of Debian. If systemd becomes _the_
> init system of focus in Debian (by vote, not only de facto), kFreeBSD
> and Hurd will
Hi Mike,
On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote:
> root@minobo:~# apt-rdepends -r systemd | wc -l
> 6598
It's not as bad as you think: the important package is systemd-sysv.
In buster:
$ apt-cache rdepends systemd-sysv
In bullseye:
systemd-sysv
Reverse Depends:
Hi,
On Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote:
No, the difference intended between choice 2 and 3 is about how we
handle technologies like elogind, or a mythical technology that parsed
sysusers files, rather than how we handle starting daemons.
I'd suggest leaving elogind entirely
On Sa 09 Nov 2019 19:09:35 CET, Holger Levsen wrote:
On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote:
(Option 1.1.1)
Automated variant transitions shall be supported.
[Rationale: moving from systemd to sysvinit is currently an involved manual
process, so unavailable to anyone
Hi,
On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote:
> > (Option 1)
> > The Debian Project aims at providing the greatest configuration flexibility
> > while maintaining a sensible default installation for end users. To that
> > end, we document functional dependencies in a
Simon Richter writes:
> the main problem I see with this GR is that it is in essence a rehash of
> the GR[1] we had in 2014, with pretty much the same options minus the
> one that won, "A GR is not required."
I voted that option in 2014 and definitely will not be voting that option
today, for
On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote:
> the main problem I see with this GR is that it is in essence a rehash of
> the GR[1] we had in 2014, with pretty much the same options minus the one
> that won, "A GR is not required."
The option that won is worded like this:
"""
Hi,
the main problem I see with this GR is that it is in essence a rehash of
the GR[1] we had in 2014, with pretty much the same options minus the one
that won, "A GR is not required."
> Choice 1: Affirm Init Diversity
The way this is worded is even stronger than in the 2014 GR, which made
Hello Wouter,
Wouter Verhelst [2019-11-09 10:32 +0200]:
> > Choice 1: Affirm Init Diversity
> >
> > Being able to run Debian systems with init systems other than systemd
> > continues to be something that the project values. With one
> > exception, the Debian Project affirms the current policy
Hello all,
Sam Hartman [2019-11-07 13:04 -0500]:
> I hope my actions demonstrate that I've tried to work with and understand the
> needs of all sides here; that has been my intent.
Many thanks! (Again, in public now :-) )
Full disclosure: I discussed that with Sam in private before, as
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>
> 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.
You can formally propose a GR today, and I recommend you do -- otherwise
we end up discussing
Hello,
On Fri 08 Nov 2019 at 06:04PM +01, Ansgar wrote:
> No, but maybe I expressed myself badly: we have people that complain
> that building Debian source packages with a Debian-specific command is a
> too high burden. This is independent of how source is represented (Git,
> .dsc, rpm,
Sean Whitton writes:
> On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote:
>> We already have people complaining that source packages are "too Debian
>> specific" and should be replaced. The tooling above is even more of a
>> problem as third parties currently have to deal with way too many
>>
Hello,
On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote:
> We already have people complaining that source packages are "too Debian
> specific" and should be replaced. The tooling above is even more of a
> problem as third parties currently have to deal with way too many
> different ways to even
Holger Levsen writes:
> On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>>
>> version 2330c05afa4
[...]
>> Choice 3: systemd without Diversity as a Priority
> [...]
>
> I guess this option will get ammendments:
>
> a.) 'systemd without
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>
> version 2330c05afa4
> Choice 1: Affirm Init Diversity
[...]
looks generally like a fine option to me.
> Choice 2: systemd but we Support Exploring Alternatives
[...]
as others have said,
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>
> version 2330c05afa4
>
> Using its power under Constitution section 4.1 (5)
I fail to see why Constitution section 4.1 (5) is referred here. I'd
better understand section 4.1 (4) and would
Sam Hartman writes:
> At this point, the question is whether the choices that need to be on
> the ballot are represented in this draft GR.
[...]
>
> version 2330c05afa4
[...]
> Choice 1: Affirm Init Diversity
>
> Being able to run Debian systems with init
On 07/11/19 at 13:59 -0500, Sam Hartman wrote:
>
> Thanks for helping; resolving these sort of ambiguities are really
> appreciated.
>
> > "Lucas" == Lucas Nussbaum writes:
>
> Lucas> Hi,
> Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
> >> Choice 2: systemd but we
Sam Hartman writes:
> That sentence does not express a preference between init scripts and
> service units: as you point out both work on systemd.
> So I think we read the same so far.
Note that we're currently discussing whether Policy will recommend
(should) that any package with a service
Hi,
On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
> Choice 2: systemd but we Support Exploring Alternatives
>
>
> The Debian project recognizes that systemd service units are the
> preferred configuration for describing how to start a daemon/service.
> However, Debian remains an environment
Thanks for helping; resolving these sort of ambiguities are really
appreciated.
> "Lucas" == Lucas Nussbaum writes:
Lucas> Hi,
Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
>> Choice 2: systemd but we Support Exploring Alternatives
>> Packages should include
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.
At this point, the question is whether the choices that need to be on
the ballot are represented in this draft GR.
I did not obtain a review of this version from
79 matches
Mail list logo
