Hi,
Not sure if I am able to vote on the issue; however, having been a Debian user
for two years and a Linux user for nearly six years and having used a number of
different distros in my time. I would like to vote in favour of keeping the
traditional freedom of choice for init systems in line
Le dim. 19 oct. 2014 à 10:54, John James
a écrit :
Hi,
Hi John,
Not sure if I am able to vote on the issue; however, having been a
Debian user for two years and a Linux user for nearly six years and
having used a number of different distros in my time. I would like to
vote in favour of
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
> packages MUST work with some alternat
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, the
> DPL has proposed an amendm
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 basically functional."
The qu
Ansgar Burchardt writes ("Re: Re-Proposal - preserve freedom of choice of init
systems"):
> Ian Jackson writes:
> > 2. Loose coupling of init systems
> >
> > In general, software may not require a specific init system to be
> > pid 1. The exceptions to this are as follows:
>
> Could you chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
(CC secretary@ to avoid this getting overlooked in the mail flood.)
I hereby formally propose the amendment below (Constitution A.1(1)
`directly by proposer'), and, then, immediately accept it (A.1(2)).
This resets the minimum discussion period (A.2
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
Lucas Nussbaum writes ("Re: GR option text on ballots"):
> I'd like to propose:
I would like to reiterate my view that these summaries should be
positive, and written by the proponent of each version, so long as
they are not misleading.
IMO summary lines should certainly not be written by opponen
Le Sat, Oct 18, 2014 at 05:31:28PM +0200, Matthias Urlichs a écrit :
>
> Charles Plessy:
> > This is why I am proposing this amendement, to say: “this GR was a bad idea,
> > please do not do it again”.
> >
> I would not regard it as an amendment, but as a separate alternative option
> on the ball
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 resolution will be i
I'm an end user who normally only reads this list. I'd like to add my
perspective to this question though, for what it's worth. I'm on Debian
testing, which is using systemd now. The only obvious difference to me
is my laptop boots faster, which is nice, but ...
1) Binary logs? No. Even I've u
Hi Charles,
On 19/10/14 at 23:29 +0900, Charles Plessy wrote:
> Le Sat, Oct 18, 2014 at 05:31:28PM +0200, Matthias Urlichs a écrit :
> >
> > Charles Plessy:
> > > This is why I am proposing this amendement, to say: “this GR was a bad
> > > idea,
> > > please do not do it again”.
> > >
> > I wou
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
>
Hi,
Charles Plessy:
> ---
>
> The Debian project asks its members to be considerate when proposing General
> Resolutions, as the GR process may be disruptive regardless of the outcome of
> the vote.
>
> Regarding the subject
Hi,
Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto:
> I hereby formally propose the amendment below (Constitution A.1(1)
> `directly by proposer'), and, then, immediately accept it (A.1(2)).
> This resets the minimum discussion period (A.2(4)).
>
> For the avoidance of any do
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
On 17 October 2014 20:07, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Re-Proposal - preserve freedom of choice of init
> systems"):
>> If you agree that this is only a matter of general technical policy, and
>> that the current state of jessie matches what you would like to see
>> after your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ian Jackson writes ("Amendment (Re: Re-Proposal - preserve freedom of choice of
init systems)"):
>And, renumber the already-existing section 3 to be section 4:
>
>- 3. Notes and rubric
>+ 3. Notes and rubric
Don points out to me in pri
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:
> If the Secretary feels we have to have a neutral rather than a
> positive phrasing I would request that we use the following summary
> line for my proposal:
>
> Packages may not require a specific init system
Why not s/a/one/ as in your amendment?
Best,
-Nikolaus
--
GPG
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 interfaces) would solve all your
>> worries
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 multiple
> forks of one init system are pres
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 that
>>> provides -- most of -- the
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
28 matches
Mail list logo
