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
johnja...@broken-pixel.co.uk 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
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 alternative
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 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 basically functional.
The question
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 change the
-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
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 this:
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 opponents
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 ballot. If I
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 important
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'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
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 would not regard it
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
enable all
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 of
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 doubt,
On 17 October 2014 20:07, Ian Jackson ijack...@chiark.greenend.org.uk 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
-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 private
Jonas Smedegaard d...@jones.dk 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
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 present
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 *surprise*
Quoting Nikolaus Rath (2014-10-19 20:16:37)
Jonas Smedegaard d...@jones.dk 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
Quoting Nikolaus Rath (2014-10-19 20:21:59)
Ian Jackson ijack...@chiark.greenend.org.uk 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
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
27 matches
Mail list logo
