Hi,
It is now clear that we will have a vote on this issue. I think that we
should use this opportunity to clarify the Project's position, and that's
not something that would be achieved if "Further Discussion" were to
win.
I am therefore bringing forward an alternative proposal, deeply inspired
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about t
Hi,
On Freitag, 17. Oktober 2014, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally writte
Hi,
On 17/10/14 12:44 AM, Lucas Nussbaum wrote:
> Hi,
>
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
>
> I am the
Seconded.
On Oct 17, Lucas Nussbaum wrote:
>It is now clear that we will have a vote on this issue. I think that we
>should use this opportunity to clarify the Project's position, and that's
>not something that would be achieved if "Further Discussion" were to
>win.
>
>I am therefore bringing fo
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>For the jessie release, all software that currently supports being run
>under sysvinit should continue to support sysvinit unless there is no
>technically feasible way to do so.
I believe "currently" needs to be clarified
Seconded.
> - begin proposal ->8
> Debian has decided (via the technical committee) to change its default
> init system for the next release. The technical committee decided not to
> decide about the question of "coupling" i.e. whether other packages
On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> >For the jessie release, all software that currently supports being run
> >under sysvinit should continue to support sysvinit unless there is no
> >technically feasible w
On 17/10/14 at 09:44 +0200, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Ru
Hi,
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> […]
>For the jessie release, all software that currently supports being run
>under sysvinit should continue to support sysvinit unless there is no
>technically feasible way to do so. Reasonable changes to preserve
>
On Fri, Oct 17, 2014 at 12:00:03PM +0100, Iain Lane wrote:
> Also, what does "currently" ("already" in my text) mean? In stable or
> testing?
Okay, I see <20141017110531.ga11...@xanadu.blop.info> now.
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer
On 17/10/14 at 12:00 +0100, Iain Lane wrote:
> Hi,
>
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > […]
> >For the jessie release, all software that currently supports being run
> >under sysvinit should continue to support sysvinit unless there is no
> >technical
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal
Recieved, and verified. Note, this has been proposed by the current
Project Leader, and thus does not require seconds, but will record those
seconding anyway.
Neil
--
signa
On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > >For the jessie release, all software that currently supports being run
> > >under sysvinit should conti
On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
> On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> > On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > > >For the jessie release, all software that currentl
On 17 October 2014 13:44, Neil McGovern wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>> I am therefore bringing forward an alternative proposal
>
> Recieved, and verified. Note, this has been proposed by the current
> Project Leader, and thus does not require seconds, b
On Fri, Oct 17, 2014 at 03:25:03PM +0200, Lucas Nussbaum wrote:
> On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
> > On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
> > > On 17/10/14 at 11:38 +0200, Michael Banck wrote:
> > > > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussb
Hi,
Lucas Nussbaum:
> For example, Ian's "software may not require a specific init system to be pid
> 1" could be abused by introducing a systemd-clone package in the archive
Please try to ignore maleficial intent and similar failure modes.
If we'd go that way, not only would we need to define (
On 17/10/14 at 16:12 +0200, Matthias Urlichs wrote:
> Hi,
>
> Lucas Nussbaum:
> > For example, Ian's "software may not require a specific init system to be
> > pid
> > 1" could be abused by introducing a systemd-clone package in the archive
>
> Please try to ignore maleficial intent and similar
On 10/17/2014 03:44 AM, Lucas Nussbaum wrote:
> Hi,
>
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
>
> I am theref
On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > I am therefore bringing forward an alternative proposal
>
> Recieved, and verified. Note, this has been proposed by the current
> Project Leader, and thus does not r
Lucas Nussbaum wrote:
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win.
>
> I am therefore bringing forward an alternati
Hi,
Joey Hess writes:
> Lucas Nussbaum wrote:
>> I am therefore bringing forward an alternative proposal, deeply inspired
>> from the "Advice: sysvinit compatibility in jessie and multiple init
>> support" option of the TC resolution on init system coupling[1], which
>> was originally written by
Ansgar Burchardt writes ("Re: Alternative proposal: support for alternative
init systems is desirable but not mandatory"):
> However it implicitly allowed changing the details later without a GR by
> just setting "inital policy".
>
> Maybe something similar coul
On 17/10/14 at 19:42 +0200, Kurt Roeckx wrote:
> On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
> > On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> > > I am therefore bringing forward an alternative proposal
> >
> > Recieved, and verified. Note, this has been prop
Hi,
On 17/10/14 at 13:02 +0200, Lucas Nussbaum wrote:
> Actually, I wonder if both proposals shouldn't be rewritten using RFC 2119 to
> make them clearer.
I did not really do that, but instead rewrote both proposals as a set of
Q&A that make it easier to understand the differences and the possibl
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
> Hi,
>
> It is now clear that we will have a vote on this issue. I think that we
> should use this opportunity to clarify the Project's position, and that's
> not something that would be achieved if "Further Discussion" were to
> win
On Friday 17 October 2014 23:03:37 Wouter Verhelst wrote:
[snip]
> I would like to see the above clause modified like this:
>
> "There may be some loss of functionality under sysvinit if the package
> is still basically functional."
>
> Rationale: I don't think that "the maintainer believes the
Thanks a lot for your analysis, Lucas. I find it _very_ helpful!
Quoting Lucas Nussbaum (2014-10-17 22:23:14)
> Q2: support for alternative init systems as PID 1
> =
> A2.1: packages MUST work with all alternative init systems as PID 1.
> (tha
On 18/10/14 at 04:14 +0200, Jonas Smedegaard wrote:
> Thanks a lot for your analysis, Lucas. I find it _very_ helpful!
>
> Quoting Lucas Nussbaum (2014-10-17 22:23:14)
> > Q2: support for alternative init systems as PID 1
> > =
> > A2.1: packages MU
On Fri, October 17, 2014 19:42, Kurt Roeckx wrote:
> On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
>> On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
>> > I am therefore bringing forward an alternative proposal
>>
>> Recieved, and verified. Note, this has been propo
Lucas Nussbaum writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> I don't think that it's useful to change this rule to:
> packages MUST work with at least one alternative init system as PID 1
> or
>
Thijs Kinkhorst writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> Does the constituion has a concept of hats? You're either the DPL or
> you're not. It seems Lucas is the DPL. If Lucas proposes an amendment,
Wouter Verhelst writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> I would like to see the above clause modified like this:
>
> "There may be some loss of functionality under sysvinit if the package
> is still
On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
[snip]
> The wording in my resolution comes from the TC discussion and
> specifies `at least one' or `some alternative'. To represent that as
> `all' is IMO misleading.
>
> One important difference between `all' and `at least one' is t
Quoting David Weinehall (2014-10-19 16:13:18)
> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
> [snip]
>
>> The wording in my resolution comes from the TC discussion and
>> specifies `at least one' or `some alternative'. To represent that as
>> `all' is IMO misleading.
>>
>> One i
David Weinehall writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> OK, so packaging uselessd (thus providing another init system that
> provides -- most of -- the systemd interfaces) would solve all your
> worries?
This
On 19/10/14 at 14:28 +0100, Ian Jackson wrote:
> > So I think that we are down to two solutions that really preserve the
> > 'freedom'
> > to choose an init system:
>
> I mostly agree with your technical analysis.
>
> > 2) packages MUST work with a specific interface, which is basic enough to
>
On 19 October 2014 18:27, Lucas Nussbaum wrote:
> On 19/10/14 at 14:28 +0100, Ian Jackson wrote:
>> > So I think that we are down to two solutions that really preserve the
>> > 'freedom'
>> > to choose an init system:
>>
>> I mostly agree with your technical analysis.
>>
>> > 2) packages MUST wor
Jonas Smedegaard writes:
> Quoting David Weinehall (2014-10-19 16:13:18)
>> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
>> [snip]
>>
>>> The wording in my resolution comes from the TC discussion and
>>> specifies `at least one' or `some alternative'. To represent that as
>>> `a
Ian Jackson writes:
> David Weinehall writes ("Re: Alternative proposal: support for alternative
> init systems is desirable but not mandatory"):
>> OK, so packaging uselessd (thus providing another init system that
>> provides -- most of -- the systemd inte
Aigars Mahinovs writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> I am inclined to agree with Lucas here - requirement of 'at least one'
> or 'some alternative' are quite imprecise, especially if mul
Hi,
Ian Jackson:
> or it might be that all
> our daemon packages end up adopting some common startup framework
> whose implementation in the sysvinit package is buggy or defective, or
> something.
>
Mmh. s/all/many/ s/adopting some common startup framework/using socket
activation/, which *surpris
Quoting Nikolaus Rath (2014-10-19 20:16:37)
> Jonas Smedegaard writes:
>> Quoting David Weinehall (2014-10-19 16:13:18)
>>> On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
>>> [snip]
>>>
The wording in my resolution comes from the TC discussion and
specifies `at least one'
Quoting Nikolaus Rath (2014-10-19 20:21:59)
> Ian Jackson writes:
>> David Weinehall writes ("Re: Alternative proposal: support for alternative
>> init systems is desirable but not mandatory"):
>>> OK, so packaging uselessd (thus providing another init system th
On Sun, Oct 19, 2014 at 11:16:37AM -0700, Nikolaus Rath wrote:
> Do you consider uselessd to be the same init system as systemd? To me
> this looks like a legitimate fork.
Albeit one that isn't in the archive; there's an RFP bug[1] but noone
has taken ownership of it / created an ITP.
--
To UNS
Jonas Smedegaard writes:
> Quoting Nikolaus Rath (2014-10-19 20:21:59)
>> Ian Jackson writes:
>>> David Weinehall writes ("Re: Alternative proposal: support for alternative
>>> init systems is desirable but not mandatory"):
>>>> OK, so packaging
Jonas Smedegaard writes:
> Quoting Nikolaus Rath (2014-10-19 20:16:37)
>> Jonas Smedegaard writes:
>>> Quoting David Weinehall (2014-10-19 16:13:18)
On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote:
[snip]
> The wording in my resolution comes from the TC discussion a
Quoting Nikolaus Rath (2014-10-20 05:19:03)
> Jonas Smedegaard writes:
>> Quoting Nikolaus Rath (2014-10-19 20:16:37)
>>> Do you consider uselessd to be the same init system as systemd? To
>>> me this looks like a legitimate fork.
>>>
>>> Or are you saying that "at least one" is really meant to m
Nikolaus Rath writes:
> I just don't understand why you consider uselessd a "trick" that I came
> up with (leaving alone the fact that David brought it up here, and that
> yet another guy started the project).
Indeed, I think uselessd is a very interesting project. I hope it
succeeds at its goa
Nikolaus Rath writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> I just don't understand why you consider uselessd a "trick" that I came
> up with (leaving alone the fact that David brought it up here, and tha
Quoting Nikolaus Rath (2014-10-20 05:29:10)
> Jonas Smedegaard writes:
>> Quoting Nikolaus Rath (2014-10-19 20:21:59)
>>> Ian Jackson writes:
>>>> David Weinehall writes ("Re: Alternative proposal: support for alternative
>>>> init systems
+1 keep `sysvint-core` in Debian *at a reliable level*, is a wise thing to
do. For at least, 2018~2020.
On 19 October 2014 18:40, Jonas Smedegaard wrote:
> Quoting Nikolaus Rath (2014-10-19 20:16:37)
> > Jonas Smedegaard writes:
> >> Quoting David Weinehall (2014-10-19 16:13:18)
> >>> On Sun, O
> "Joey" == Joey Hess writes:
Joey> Why not just make your proposal be something along the lines
Joey> of reaffirming the technical decision-making process as it
Joey> currently stands, from the package maintainers, to the policy,
Joey> to the TC. It could implicitly or expli
Sam Hartman wrote:
> > "Joey" == Joey Hess writes:
>
> Joey> Why not just make your proposal be something along the lines
> Joey> of reaffirming the technical decision-making process as it
> Joey> currently stands, from the package maintainers, to the policy,
> Joey> to the TC
Ian Jackson writes:
> Nikolaus Rath writes ("Re: Alternative proposal: support for alternative init
> systems is desirable but not mandatory"):
>> I just don't understand why you consider uselessd a "trick" that I came
>> up with (leaving alone the f
Quoting Nikolaus Rath (2014-10-21 02:41:12)
> Ian Jackson writes:
>> Nikolaus Rath writes ("Re: Alternative proposal: support for alternative
>> init systems is desirable but not mandatory"):
>>> I just don't understand why you consider uselessd a "t
Hi,
On 20/10/14 at 14:47 -0400, Sam Hartman wrote:
> > "Joey" == Joey Hess writes:
>
> Joey> Why not just make your proposal be something along the lines
> Joey> of reaffirming the technical decision-making process as it
> Joey> currently stands, from the package maintainers, to
Lucas Nussbaum writes:
> During the TC discussions in January/February 2014, the TC had a small
> legitimacy crisis, that resulted in the GR override clause of the
> default init resolution. I hope that the result of this GR will be able
> to serve as input in future TC discussions on similar/rel
59 matches
Mail list logo
