Re: Withdrawal of Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Matthew Vernon writes ("Withdrawal of Proposal - preserve freedom of choice of 
init systems"):
> Matthew Vernon writes:
>  > I wish to propose the following general resolution, and hereby call
>  > for seconds. I don't think further lengthy discussion of the issues is
> 
> 
> 
> I said that if I'd not received enough seconds by today that I would
> withdraw this GR proposal. Despite one person emailing me off-list to
> urge me to continue, I think it's important to do what I said I would
> do, so I hereby withdraw this GR proposal.

Thanks, Matthew.  I'm disappointed of course that this didn't get more
support, but under the circumstances it's clear that withdrawing this
proposal now is the right thing to do.

Regards,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21287.13328.597192.950...@chiark.greenend.org.uk

Withdrawal of Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Matthew Vernon writes:
 
 > I wish to propose the following general resolution, and hereby call
 > for seconds. I don't think further lengthy discussion of the issues is



I said that if I'd not received enough seconds by today that I would
withdraw this GR proposal. Despite one person emailing me off-list to
urge me to continue, I think it's important to do what I said I would
do, so I hereby withdraw this GR proposal.

Thanks to everyone who commented on this proposal; whilst I didn't
reply to all of your comments by any means, I did read them all.

Regards,

Matthew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iQIVAwUBUycwHBL00hyPamPIAQia3A/+PdsKganGlVTaxh31YbfILhErsKQ2kKjb
9TomVWOo4Iclks+w1LWrFwJSYG4tz07GJFnWi5Syc4tQfFVIzNt4bizBgvGUTjzD
/EI7Q9CLHHjZ7MVQe1GMAXgew3LGsE72EwDfsyn+15ZcMcvZdcpL44tSszG3YTZc
v+TmX7TT5QrMaKsJM+KbkgKgZkFX5RfC4zWeInTprJkqWyeglmMjiZ+1gQFBnQdx
q+XI1ilFeolOh6eaQUWDOdzBdu6yxScQ/cLj9/gDMk9Mp9vM9vg37oZApezn1J+Y
ylgo92qzK+4AqIEWptR+wyc8A9YX0Y03x3qkRAPrT6vzIfuBJyuvvCBv+SZM4pSz
cTEjBYOjNs9LZc8EF3OPxlaqan81E+2jdcgcu9jaoVRSxlREcG7pDKmGp+F7NYXR
dQpSW3VlpSgf6yeL+K2LZVylAG6anXnn/NN67AL0D5Asx/dwIkcixFZ63/8/I2/E
cWiUK7zrWb6cPpejWQUHy6YuIyL5wk3Y1Pv1P62remI2ZRwRHq1My3wMjv02Y7OV
g07p8gVnhLY+TuvjIks+Dnb6LS0MG/JQrNW5A/zAOEk9aXJzuxuK+zIgu7DyVSQm
3UTKHb4Aw6QPtMmetqhdMJIeL3e+kT40t4c4BfBqb4NRWqr6e3S8nAcRNRwWkCa5
MvX50Hu0uvs=
=GgTc
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21287.12320.587622.129...@aragorn.weathertop.principate.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Stuart Prescott]

Hi Matthew,

>> Your rationale does not explain how the normal policy process has failed
>> to deliver the outcomes required by the project. I think the project
>> should
> 
> Sorry about that; I rather thought that the TC failing to rule on the
> issue was failing to provide clarity on this important issue.

Quite the contrary. The TC was never actually asked to rule on this issue. 
It is standard that the TC rules on issues when the normal processes have 
broken down in some way. As described in detail in #727708, the TC chose not 
to rule on it because the normal policy process was not broken -- in fact 
the normal policy process had barely even started. The TC is not the 
project's normal policy process any more than a GR is the project's normal 
policy process. 

I would add that picking at a sore like this *will* end up breaking the 
normal policy process; we're dealing with self-fulfilling prophecies here.

Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7




-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lfkabg$fse$1...@ger.gmane.org

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

On 10/03/14 08:58, Thibaut Paumard wrote:

> I second the general resolution proposal below:

Thanks; with you and Iustin, I have 3 seconds now; 5 are needed for the
GR to go to a vote.

Regards,

Matthew


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531da182.30...@debian.org

Re: Proposal - preserve freedom of choice of init systems

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I second the general resolution proposal below:

Kind regards, Thibaut.


Le 01/03/2014 00:45, Matthew Vernon a écrit :
> Hi,
> 
> I wish to propose the following general resolution, and hereby
> call for seconds. I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote so that the project can state its mind on
> this important issue. The substantive text is that which was
> drafted for the purposes of the technical committee's vote (where
> they decided not to pass a resolution on the subject).
> 
> Regards,
> 
> Matthew
> 
> ** Begin Proposal **
> 
> 0. Rationale
> 
> 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 in Debian may depend on a particular init
> system.
> 
> This GR seeks to preserve the freedom of our users now to select
> an init system of their choice, and the project's freedom to select
> a different init system in the future. It will avoid Debian
> becoming accidentally locked in to a particular init system (for
> example, because so much unrelated software has ended up depending
> on a particular init system that the burden of effort required to
> change init system becomes too great). A number of init systems
> exist, and it is clear that there is not yet broad consensus as to
> what the best init system might look like.
> 
> This GR does not make any comment on the relative merits of 
> different init systems; the technical committee has decided upon
> the default init system for Linux for jessie.
> 
> 1. Exercise of the TC's power to set policy
> 
> For jessie and later releases, the TC's power to set technical 
> policy (Constitution 6.1.1) is exercised as follows:
> 
> 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:
> 
> * alternative init system implementations * special-use packages
> such as managers for init systems * cooperating groups of packages
> intended for use with specific init systems
> 
> provided that these are not themselves required by other software 
> whose main purpose is not the operation of a specific init system.
> 
> Degraded operation with some init systems is tolerable, so long as 
> the degradation is no worse than what the Debian project would 
> consider a tolerable (non-RC) bug even if it were affecting all 
> users.  So the lack of support for a particular init system does
> not excuse a bug nor reduce its severity; but conversely, nor is a
> bug more serious simply because it is an incompatibility of some
> software with some init system(s).
> 
> Maintainers are encouraged to accept technically sound patches to
> enable improved interoperation with various init systems.
> 
> 3. Notes and rubric
> 
> This resolution is a Position Statement about Issues of the Day 
> (Constitution 4.1.5), triggering the General Resolution override 
> clause in the TC's resolution of the 11th of February.
> 
> The TC's decision on the default init system for Linux in jessie 
> stands undisturbed.
> 
> However, the TC resolution is altered to add the additional text in
> sections (1) and (2) above.
> 
> ** End Proposal **
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTHX6NAAoJEJOUU0jg3ChA3e8QANd2EpYpVNWBbKN7lzW0oQgD
h8l5zdChw8bUuowWQd3STjEbAwxgjxA0UHtZ0zeHFMI9vfZlzAg7UMAF9+mJ5Wbx
I3eif/MCYJlPCLJPNwKAQX94z+mbmm+r9dMSk1hpx5OQzdSZ+IqBZpAtGwYRhDxT
HXgTh/5cTPiFv8dxYbeiDaAjF00HY7BztfMztOx0LPXmW4mYK01c1mAJPe70d+cv
zwRSkKmtJMF0B9Y+D7AEGkBdSpEQmu6JkD8/XbK3326Y/l+E0DdGe4JqgyCrLYI3
x8tCG68c9R5cvTY6Dv6fyLZJVMkRGnHdrK0VsdocAlAgF81dmfX/rI+oL8QnfcoK
kQwhHIkSrR03OJ/SGDvDiH1rmVx42Dz9I1OQlg/Ho28SKQeeQoiJmZvJpZgfpe5V
1JdRe8d07cwfJKrdP6hLtVMjm063ROyW8/H7GnDMy4hO0FI9N7EYgKPyL2HUOza/
+aMu5baNQUueXsYvX9LlW88RmuRAciEmQCAnxyPMQS7LJfQLm5+DMzG/DkOjdAzM
I6VoTug4wg+/5JTGz0icCuKscc9FEdZ546J8nQpj0g88v8ByvQBs8wH1q8jUL80U
mQyqh/fphsjMSDJ74lhWEme8TDbzLv3/9BoycdbqZ5USJPWyqbC1AigsemST7nnn
mRjPHMW7+jQhCWf0Ya+j
=W4+2
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531d7e99.6040...@debian.org

Re: Proposal - preserve freedom of choice of init systems

[Iustin Pop]

On Fri, Mar 07, 2014 at 09:52:54AM +, Matthew Vernon wrote:
> Hi,
> 
> Matthew Vernon  writes:
> 
> > I wish to propose the following general resolution, and hereby call
> > for seconds. I don't think further lengthy discussion of the issues is
> 
> 
> 
> This has only had one second. In order to not prolong things
> indefinitely, I'll withdraw this GR if it's not got sufficient seconds
> by Monday 17th; that's about another week.

Well, in that case, seconded. Let me know if this is not the proper way
to second a proposal.

regards,
iustin


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

Thibaut Paumard  writes:

> I am still waiting for your answer to my concerns before I make my mind
> on seconding this GR:
> https://lists.debian.org/debian-project/2014/03/msg00024.html
> 
> The problem, I think, is that the discussion was drawn onto procedural
> technicalities rather than discussing the the actual content of your GR.

I see Ian has just addressed this in -project; I don't feel the need
to expand on what he said.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5bk3c60zxo@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Thibaut Paumard writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> I wonder whether this GR has the following corollary:

As the author of the TC text (which Matthew has simply adopted), I
think I can clarify this.  What I'm about to say will come as no
surprise to anyone who followed the relevant parts of the TC
discussion.

> "Packages shipping services or daemons must ship whatever is required to
> start and stop said service by any init system introduced in Debian in
> the past and future", which I think would be bad.

No.  It only says software may not "require _a_ specific init system"
(emphasis mine).  The text does not rule out a package supporting only
some subset of the available init systems - so long as that subset has
more than one member.

In practice so long as a package supports more than one init system,
making it support all init systems is a feasible (or even
straightforward) task.

> Also, is that OK for a package to Recommend a specific init system
> rather that Depend on it?

It doesn't talk about Depends or Recommends.  It talks about whether
the program works (or doesn't).

I think that "degraded operation" is exactly what one would expect
with a violated Recommends.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21273.49252.708586.774...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Thibaut Paumard]

Le 07/03/2014 10:52, Matthew Vernon a écrit :
>> I wish to propose the following general resolution,
> This has only had one second. 

Dear Matthew,

I am still waiting for your answer to my concerns before I make my mind
on seconding this GR:
https://lists.debian.org/debian-project/2014/03/msg00024.html

The problem, I think, is that the discussion was drawn onto procedural
technicalities rather than discussing the the actual content of your GR.

Kind regards, Thibaut.




signature.asc
Description: OpenPGP digital signature

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

Matthew Vernon  writes:

> I wish to propose the following general resolution, and hereby call
> for seconds. I don't think further lengthy discussion of the issues is



This has only had one second. In order to not prolong things
indefinitely, I'll withdraw this GR if it's not got sufficient seconds
by Monday 17th; that's about another week.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5bpply1gjt@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Uwe Storbeck]

Ian Jackson writes:
> What my TC text, as adopted in Matthew's proposal, does is to answer
> the question: what happens if the work is not done ?

When you assume the work is not done then there will be packages
which do not support all init systems and depend (directly or
indirectly) on certain of them. These packages will have to be
dropped from the repository (or not to be included into it) when
this proposal is accepted.

Now lets see how this affects Debian users with different init
systems.

Users of the least supported init system will have the same
number of installable packages for their system, with or without
this proposal. Packages which depend on other init systems will
either not be installable with their init system (because of the
dependencies) or are not part of the repository anymore, when the
proposal is accepted.

Users of any other non-default init system will have (slightly)
more installable packages without this proposal, as there may be
some packages which support their init system, but do not support
all init systems and therefore have to be dropped from the
repository when the proposal is accepted.

Users of the default init system will have more installable
packages without this proposal as most packages should support
the default init system and packages which do support the default
init system, but not all of the others, will have to be dropped
when the proposal is accepted.

As a summary, when you assume the work is not done, none of the
users of different init systems will benefit from this proposal.
None of them will have more packages to select from.

The only way somebody may benefit from this proposal is when you
assume the work gets done, done by people who otherwise would not
be interested to do the work (for people who would do the work
voluntarily this proposal is not needed).

> It answers this question: Suppose the work is not done.  Ultimately
> then we would have to drop either (a) GNOME or (b) non-systemd init
> systems, and non-Linux kernels.

You are only forced to drop one of them when the proposal gets
accepted, otherwise they can coexist in the repository.

Uwe


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140304024638.ga6...@ibr.ch

Re: Proposal - preserve freedom of choice of init systems

[Zenaan Harkness]

Once again, you rant multiple lists whilst hiding who you are.

I am Zenaan Harkness. I have some (not all) strongly held views.

As an aside, I shall use systemd and have tried a few times now, but
have a technical issue or two with my setup when using systemd, which
I need to find time to solve first - I intend to use systemd as
default init regardless of the outcome of any GR that may or may not
happen - I really do read and appreciate the technical superiority of
systemd, even though I have since a year now been unable to find time
to solve the issue stopping me from using it.

I don't hide behind a "persona" which is clearly political in its
agenda - and you hypocritically accuse others of being political... OH
the irony!


On 3/3/14, Natural Linux  wrote:
> "Clearly such blatent politicking tarnishes that respect, and I'd imagine"
> "this is becoming a popular point of view."
> "
> "Cheers,"
> "  Paul"
>
> Says the systemd camp, which uses politics in every fight it wages

Notwithstanding, your email is not politics?

No name?

A persona "Natural Linux" - makes me wonder if you're into nude
bushwalking or something.


> (and it usually wins). Using the tech-ctte to change the OS in a
> fundamental way itself is an abuse of power, in an improper venue

Abuse of power claimed, by an anonymous _you_, and AFTER the fact.

Come on, you need to try a little harder for a truly good troll.

Don't get me wrong - you might have some important views and you might
have some significant contributions to make to the future of Debian,
but you are doing a sterlingly poor job of marketing these views you
hold.

It might be that you are simply not aware of how bad you are
presenting yourself. Firstly you need to cool down. Then, you need to
be honest - go public (I'm sure many of us guess who you are, but hey,
we ought assume you have good intentions) as in, don't hide behind
your personas (and you really ought to avoid attaching other's
personas when you yourself are using one - we call that hypocrisy, and
really bad marketing too).


> created to decide disagreements among package maintainers, not
> to go around everyone's backs and make sweeping changes to the
> core of debian linux. I think Ian even pointed out that the
> technical committe was the improper venue.

There must be avenues for proposing changes to the Debian structures,
if process is lacking, invent it and propose that first.

If you truly hold the beliefs you are less that successfully
promoting, then hold a steady course ... and good luck.


> Also I read all the emails, everyone said that a GR with more than
> 50 percent vote should be able to override said decision.
> Then systemd won 4 votes to 4, and now the systemd camp opposes
> anyone holding a general resolution and is trying to stall and
> not allow such a thing to be called.

A classic case of FUD, preying on the lack of knowledge of (some of)
your readers to assert (by implication) bad intentions and actions
which are not possible.

Again, really bad form if you have some good points in there somewhere.


> Pulling the ladder up after you've achived your improper victory
> (through politics). Note from whom the systemd camp derives their
> salarys and income.

More of the same.


> But yea, anyone who stands up against systemd is a troll, or dissapointing.

Baseless reverse-psychology assertions.


> Four people get to decide what operating system debian is.
> Four. And we have to accept that for some reason.

Not four. Eight! They don't get to decide. They DID decide!

If you think a GR will get up, stop hiding behind your persona and
propose it. I highly doubt such a GR would get the votes though - make
Debian a black sheep of the GNU/Linux world? Unlikely that 50%+1 DDs
would vote for that, NOTWITHSTANDING all the technical reasons for the
(apparent) superiority of systemd...


I shall refrain from calling you a troll. I assume you have strongly
held, yet fundamentally good, intentions, and are simply failing
dismally to communicate effectively at this point in time.

So good luck, and if you want respect, you might try toning it down a bit,
Zenaan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnsrwj_e2-fe1zvochx8bwxmuwo3jjxvpjnzdmmk3a+0...@mail.gmail.com

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Mon, Mar 03, 2014 at 11:39:40AM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> > > That doesn't contradict the GR.  If the GR passes we have two
> > > resolutions:
> > > 
> > >  11th Feb as modified by GR: sysvinit as default, loose coupling
> > >  28th Feb "we choose not to pass a resolution at the current time
> > >[ie on the 28th of February] about coupling"
> > > 
> > > These are not contradictory.  In particular, the 28th of February
> > > resolution should not be read as vacating the 11th of February
> > > resolution's GR rider, which is what you are suggesting.
> > 
> > I'm not disagreeing that you're allowed to do it, I'm disagreeing
> > that it's a good idea to do it.
> 
> Does that mean that you are now tending towards the view that
> Matthew's proposal requires only a simple 1:1 majority ?

Yes.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140303210532.gc15...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Olav Vitters]

On Mon, Mar 03, 2014 at 12:15:37PM +, Ian Jackson wrote:
> Russ Allbery writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > Since, in my opinion, this question is all about how the project wants to
> > govern itself and how we want to handle assigning responsibility for work
> 
> I don't think this is the right way to look at it.  We are a volunteer
> project and we can't assign work to people.
> 
> What my TC text, as adopted in Matthew's proposal, does is to answer
> the question: what happens if the work is not done ?

The text is too vague to be useful.

> It answers this question: Suppose the work is not done.  Ultimately
> then we would have to drop either (a) GNOME or (b) non-systemd init
> systems, and non-Linux kernels.  What choice should we make ?

There are lots of other possibilities that have been raised that you
seem to conveniently ignore.

> For me the answer is: We should preserve diversity and freedom of
> choice, at the cost of functionality.  Making that statement now,
> very clearly, will make that doomsday scenario less likely.

I think your continued way of not talking to e.g. GNOME despite being
invited, while at the same time forcing work on the very people who
invite you to talk is very unfortunate.

"Doomsday scenario" is not going to happen due to the things stated in
Russ' email. GNOME is addressing this with help of others.

-- 
Regards,
Olav (expecting to be totally ignored again)


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140303134634.ga24...@bkor.dhs.org

Re: Proposal - preserve freedom of choice of init systems

[Holger Levsen]

Hi,

On Montag, 3. März 2014, Tollef Fog Heen wrote:
> It's a false dichtonomy, we could say that GNOME doesn't work on those
> platforms.  That'd be sad, but it wouldn't make those platforms
> unusable, nor would it make GNOME generally unusable.
> 
> It wouldn't be the first or the last time we don't have feature parity
> between ports.

that, plus it's s/GNOME/GNOME, KDE and Xfce4/g (yawning!) and yes, I think we 
should rather keep those desktops instead of the toy ports or those 
toy/historic init systems. _if_ that question ever pops up like this for real 
and not just in doomsday threads.


cheers,
Holger

P.S.: I pretty much used to dislike the term toy ports. This init system saga 
has made me change my language, not sure yet, if also constantly my mind. I 
also don't think I really like the change in language, but meh.


signature.asc
Description: This is a digitally signed message part.

Re: Proposal - preserve freedom of choice of init systems

[Tollef Fog Heen]

]] Ian Jackson 

> It answers this question: Suppose the work is not done.  Ultimately
> then we would have to drop either (a) GNOME or (b) non-systemd init
> systems, and non-Linux kernels.  What choice should we make ?

It's a false dichtonomy, we could say that GNOME doesn't work on those
platforms.  That'd be sad, but it wouldn't make those platforms
unusable, nor would it make GNOME generally unusable.

It wouldn't be the first or the last time we don't have feature parity
between ports.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbvvzcwp@xoog.err.no

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Russ Allbery writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> Since, in my opinion, this question is all about how the project wants to
> govern itself and how we want to handle assigning responsibility for work

I don't think this is the right way to look at it.  We are a volunteer
project and we can't assign work to people.

What my TC text, as adopted in Matthew's proposal, does is to answer
the question: what happens if the work is not done ?

It answers this question: Suppose the work is not done.  Ultimately
then we would have to drop either (a) GNOME or (b) non-systemd init
systems, and non-Linux kernels.  What choice should we make ?

For me the answer is: We should preserve diversity and freedom of
choice, at the cost of functionality.  Making that statement now,
very clearly, will make that doomsday scenario less likely.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21268.29289.888487.641...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Nikolaus Rath writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> I believe the point of contention is that Ian seems to imply that due to
> the way that the wrote the GR clause, *any* GR related to init would
> automatically nullify the TC's decision about the default init system --
> even if the GR doesn't say anything about the default init
> system.

I think that is the case.  I think this is a bug in the wording of the
GR rider clause.  The workaround is for such a GR to explicitly adopt
the TC decision text.  Matthew's proposal does that.

> Consequently, any GR about init-related issues would now need to
> explicity state that it upholds the CTTE's decision for the default init
> system. Lacking that, passing of the GR would, as a *side-effect*
> nullify the CT decision about the default init. I would be surprised if
> this is what the majority ofthe CTTE intended.

I think everyone on the TC agrees that this is undesirable.

Unfortunately we had some difficulty getting a GR rider text which the
Secretary accepted would be appropriately operative, and this bug was
introduced during that drafting work.  My initial proposed wording
didn't have this bug, but the Secretary's interpretation was that a GR
which tried to exercise it would still need 2:1.

Sorry for my part in causing this additional procedural annoyance.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21268.27237.800425.423...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> > That doesn't contradict the GR.  If the GR passes we have two
> > resolutions:
> > 
> >  11th Feb as modified by GR: sysvinit as default, loose coupling
> >  28th Feb "we choose not to pass a resolution at the current time
> >[ie on the 28th of February] about coupling"
> > 
> > These are not contradictory.  In particular, the 28th of February
> > resolution should not be read as vacating the 11th of February
> > resolution's GR rider, which is what you are suggesting.
> 
> I'm not disagreeing that you're allowed to do it, I'm disagreeing
> that it's a good idea to do it.

Does that mean that you are now tending towards the view that
Matthew's proposal requires only a simple 1:1 majority ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21268.27132.340202.414...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Andreas Barth writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> Iain Lane (la...@debian.org) [140302 19:28]:
> > The rest of the discussion notwithstanding, where do you think that
> > >  11th Feb as modified by GR: sysvinit as default, loose coupling
> >
> > 
> > sysvinit comes from?
> 
> I think a qualified spelling error, and should read as "systemd as
> default, loose coupling".

Oh god that mis-spelling has come back.  I have been writing
"sysvinit" for "systemd" and "systemd" for "sysvinit" half the time
throughout this whole business.

Sorry for the confusion.  Andi is right; I meant "systemd".  (My
fingers tried to do it again just there...)

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21268.26810.204225.324...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Paul Tagliamonte writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> Sorry, Ian. I overreated.

Apology accepted.  This whole business is quite difficult for
everyone and I too haven't managed to always keep my temper :-/.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21268.26374.640513.57...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

Steve Langasek  writes:

> Given the ambiguity about whether this GR vacates the earlier TC decision, I
> think it would be best to simply include in your GR text a statement that
> 
>   The Debian project reaffirms the decision of the TC to make systemd the
>   default init system for jessie.

The reason why I went for stating (twice) that my GR doesn't alter the
TC's choice of init system rather than reaffirming is that there might
be people who are unhappy about the choice but content to live with it
- and I'd like not to cause those people to vote against my GR. So I'd
be happy with changes that made it even clearer that I don't intend
to change the default (though, as I say, my text says so twice
already), but not things that may alienate those who don't want to
sign up to "systemd is great :-)".

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5b4n3f37gk@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Jonathan Dowland]

On Sun, Mar 02, 2014 at 11:07:17PM -0800, Nikolaus Rath wrote:
> Consequently, any GR about init-related issues would now need to
> explicity state that it upholds the CTTE's decision for the default
> init system. Lacking that, passing of the GR would, as a *side-effect*
> nullify the CT decision about the default init. I would be surprised
> if this is what the majority ofthe CTTE intended.

I'd be surprised if even a minority intended this. Remember that over
turning the default init will mean a lot of work. Once work has begun
on embedding systemd, what would a conspirator really expect to happen
if they popped up with "aha! a GR has reversed the CTTE decision! You
are now all compelled to put the work in to *actually* reverse it!"[1].

I continue to assume good faith.

[1] Imagine this in the vein of Monty Python's Inquisitor sketch


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140303090112.ga12...@bryant.redmars.org

Re: Proposal - preserve freedom of choice of init systems

[Nikolaus Rath]

Andreas Barth  writes:
> * Paul Tagliamonte (paul...@debian.org) [140302 19:02]:
>> On Sun, Mar 02, 2014 at 05:55:14PM +, Colin Watson wrote:
>> > Huh?  Ian explicitly says, as does the text itself, that this proposed
>> > GR *adopts* the TC decision on the default init system.  It doesn't
>> > overturn it.
>> 
>> The fact there's a backdoor that was inserted that allowed him to
>> overturn the TC decision with a GR that mentions the word init is
>> absurd.
>
> I don't know what you try to make about, but 
>
> 1. the proposed GR doesn't overturn TCs decision about the default
> Linux init system, but holds that one up and adds something about
> loose coupling of init systems and packages[1]
>
> 2. the possibility to overturn TCs decision was inserted *by*
> *purpose* with our the common understanding of all TC members that if
> the developers together want to overturn our decision they should be
> able to do so with normal (1:1) majority. This was part of the
> proposals with systemd as Linux default and also with upstart as Linux
> default.

I believe the point of contention is that Ian seems to imply that due to
the way that the wrote the GR clause, *any* GR related to init would
automatically nullify the TC's decision about the default init system --
even if the GR doesn't say anything about the default init
system. Consequently, any GR about init-related issues would now need to
explicity state that it upholds the CTTE's decision for the default init
system. Lacking that, passing of the GR would, as a *side-effect*
nullify the CT decision about the default init. I would be surprised if
this is what the majority ofthe CTTE intended.

Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mwh769qy@vostro.rath.org

Re: Proposal - preserve freedom of choice of init systems - SysV is FINE.

[Natural Linux]

System V is NOT hard to "maintain"
The scripts were written YEARS ago. They're fine. They do NOT need to be 
changed.
Debian SysV has concurrent boot aswell.

Systemd is a poison apple. 200k lines of unaudited root privlege code. A 
consulting 
service to go along with this new _operating system_

Here's an under 100 line init with concurrent boot:

#include 
#include 

int main()
{
sigset_t set;
int status;

if (getpid() != 1) return 1;

sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);

if (fork()) for (;;) wait(&status);

sigprocmask(SIG_UNBLOCK, &set, 0);

setsid();
setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

>/etc/rc is a shell script
>syslogd && getty ; udev ; network-config ; sshd & cron & nginx


see how much bullsht systemd is.

_
Washington DC's Largest FREE Email service. ---> http://www.DCemail.com ---> A 
Washington Online Community Member --->
http://www.DCpages.com


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302192648.52ada...@m0048140.ppops.net

Re: Proposal - preserve freedom of choice of init systems

[Natural Linux]

"Clearly such blatent politicking tarnishes that respect, and I'd imagine"
"this is becoming a popular point of view."
"
"Cheers,"
"  Paul"
  
Says the systemd camp, which uses politics in every fight it wages
(and it usually wins). Using the tech-ctte to change the OS in a 
fundamental way itself is an abuse of power, in an improper venue
created to decide disagreements among package maintainers, not
to go around everyone's backs and make sweeping changes to the 
core of debian linux. I think Ian even pointed out that the
technical committe was the improper venue.

Also I read all the emails, everyone said that a GR with more than
50 percent vote should be able to override said decision.
Then systemd won 4 votes to 4, and now the systemd camp opposes
anyone holding a general resolution and is trying to stall and 
not allow such a thing to be called.

Pulling the ladder up after you've achived your improper victory
(through politics). Note from whom the systemd camp derives their
salarys and income.

But yea, anyone who stands up against systemd is a troll, or dissapointing.

Four people get to decide what operating system debian is.
Four. And we have to accept that for some reason.

>Ian, I'm extremely disaspointed in this childish behavior of trying to
>insert a malicious trap-door to a decision.
>
>I'm *EXTREMELY* disaspointed in this.
>
>I'm CC'ing DAM.
>
>This is, at minimum:
>
>  1) A abuse of power (inserting a backdoor in a decision)
> *snip*

_
Washington DC's Largest FREE Email service. ---> http://www.DCemail.com ---> A 
Washington Online Community Member --->
http://www.DCpages.com


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302192748.52ada...@m0048140.ppops.net

Re: Proposal - preserve freedom of choice of init systems - Linux IS about CHOICE

[Thomas Bushnell, BSG]

Yes, by all means we should ignore the fake personas, Mr. Natural Linux,
whoever you are.


On Sun, Mar 2, 2014 at 7:25 PM, Natural Linux wrote:

> Matthias Urlichs, Why should we believe you or the bullshit excuses given
> in the article?
>
> The fact is, last year none of this crap was needed.
> Now it suddenly is.
> Furthermore gnome stole libgtk from the gimp project recently
> and then they made an incompatable "libgtk" 3.0.
>
> And now they're requiring all these bullshit daemons, and systemd.
>
> This is a political coup. We are being lead by the nose.
> Notice the arguments from the gnome and systemd people are always the same
> across all forums, for years.
>
> "It is for your own good"
> "You must join the modern era"
> They know better than us and we must join.
> Over and over again for the past year or two.
>
> I think these are the same people.
> Fake personas, or directed by their employers.
>
> They should be thrown out, we should recongise them for what they are.
>
> Real, traditional linux includes
> sysv or bsd style init (or openrc).
> libgtk2 (not 3).
> gnome2 (not 3).
>
> And no systemd.
>
> We should also take heed of Snowden's documents which show that
> the United States government, which is an evil force that
> blows up and burns alive little girls and boys in afghanistan
> iraq and elsewhere, had and has a program to subvert technology
> and software projects everywhere.
>
> Systemd and its shills are likely part of this.
> They should be thrown out of our community distributions.
> Pretty much anything by redhat is harmful nowadays.
> And anyone associated.
>
>
>
> --
> Washington DC's Largest FREE Email service. ---> http://www.DCemail.com---> A 
> Washington Online Community Member --->
> http://www.DCpages.com
>

Re: Proposal - preserve freedom of choice of init systems - Linux IS about CHOICE

[Natural Linux]

Matthias Urlichs, Why should we believe you or the bullshit excuses givenin the article?The fact is, last year none of this crap was needed.Now it suddenly is.Furthermore gnome stole libgtk from the gimp project recentlyand then they made an incompatable "libgtk" 3.0.And now they're requiring all these bullshit daemons, and systemd.This is a political coup. We are being lead by the nose.Notice the arguments from the gnome and systemd people are always the sameacross all forums, for years."It is for your own good""You must join the modern era"They know better than us and we must join.Over and over again for the past year or two.I think these are the same people.Fake personas, or directed by their employers.They should be thrown out, we should recongise them for what they are.Real, traditional linux includessysv or bsd style init (or openrc).libgtk2 (not 3). gnome2 (not 3).And no systemd.We should also take heed of Snowden's documents which show thatthe United States government, which is an evil force that blows up and burns alive little girls and boys in afghanistaniraq and elsewhere, had and has a program to subvert technologyand software projects everywhere.Systemd and its shills are likely part of this.They should be thrown out of our community distributions.Pretty much anything by redhat is harmful nowadays.And anyone associated. Washington DC's Largest FREE Email service. ---> http://www.DCemail.com ---> A Washington Online Community Member --->http://www.DCpages.com

Re: Proposal - preserve freedom of choice of init systems

[Steve Langasek]

On Sun, Mar 02, 2014 at 01:53:06PM -0800, NoTo CTTE wrote:
> Four people get to decide what operating system debian is.
> Four. And we have to accept that for some reason.

Debian developers don't have to accept it; they can pass a GR choosing a
different default if they think that systemd is the wrong choice.

*You*, OTOH, have to accept it because you're an anonymous troll whose words
carry absolutely zero weight with the Debian community.

You are this guy:

  http://www.penny-arcade.com/comic/2004/03/19

And that guy doesn't get a say in Debian's decisions.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems - Linux IS about CHOICE

[Matthias Urlichs]

*Plonk*.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Matthias Urlichs]

Hi,

Russ Allbery:
> In other words, I'm advocating the same position that we have right now
> for translations: the package maintainer is not expected to translate
> their package to other languages, but they are expected to incorporate
> translations as they are made available.  The translators bear the burden
> of the work for doing the translation, and if no one steps up to translate
> a particular package to some language, it won't be available in that
> language.
> 
Seconded. (The rest also.)

This GR would herald a major change in hwo we as a project
[are supposed to] cooperate, and IMHO *not* for the better.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[NoTo CTTE]

"Clearly such blatent politicking tarnishes that respect, and I'd imagine"
"this is becoming a popular point of view."
"
"Cheers,"
"  Paul"
  
Says the systemd camp, which uses politics in every fight it wages
(and it usually wins). Using the tech-ctte to change the OS in a 
fundamental way itself is an abuse of power, in an improper venue
created to decide disagreements among package maintainers, not
to go around everyone's backs and make sweeping changes to the 
core of debian linux. I think Ian even pointed out that the
technical committe was the improper venue.

Also I read all the emails, everyone said that a GR with more than
50 percent vote should be able to override said decision.
Then systemd won 4 votes to 4, and now the systemd camp opposes
anyone holding a general resolution and is trying to stall and 
not allow such a thing to be called.

Pulling the ladder up after you've achived your improper victory
(through politics). Note from whom the systemd camp derives their
salarys and income.

But yea, anyone who stands up against systemd is a troll, or dissapointing.

Four people get to decide what operating system debian is.
Four. And we have to accept that for some reason.

--- paul...@debian.org wrote:

From: Paul Tagliamonte 
To: Ian Jackson 
Cc: debian-v...@lists.debian.org, debian-project@lists.debian.org,  
da-mana...@debian.org
Subject: Re: Proposal - preserve freedom of choice of init systems
Date: Sun, 2 Mar 2014 12:49:22 -0500

On Sun, Mar 02, 2014 at 12:35:15PM +0000, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > > If you're going to say we need to replace "the TC resolution is
> > > amended" with something like "we wish that instead the TC had decided
> > > blah", then please reconsider.  That would force the GR to avoid
> > > saying what its own effect is, which is unnecessarily confusing.
> > > Also, writing that text is very cumbersome.
> > 
> > The text currently says it's using the TC's power to decide
> > something, and so would fall under 4.1.4.  I think the intent of
> > this GR is not to override the TC's decision about the default, so
> > I'm currently not sure what to suggest.
> 
> The TC decision of the 11th of February said:
> 
>   Should the project pass a General Resolution before the release of
>   "jessie" asserting a "position statement about issues of the day" on
>   init systems, that position replaces the outcome of this vote and is
>   adopted by the Technical Committee as its own decision.
> 
> This a GR proposal is a "position statement about issues of the day"
> (as it says in the "Notes and rubric".)  It's on the subject of init
> systems.  Therefore it is covered by this wording.
> 
> As a consequence, the GR replaces the outcome of the TC vote.  The GR
> text explicitly adopts the existing TC decision on the default, and
> adds to it.

Ian, I'm extremely disaspointed in this childish behavior of trying to
insert a malicious trap-door to a decision.

I'm *EXTREMELY* disaspointed in this.

I'm CC'ing DAM.

This is, at minimum:

  1) A abuse of power (inserting a backdoor in a decision)
  2) Dishonest (using an unrelated GR to turn over the default init
 decision made through a backdoor you put in)
  3) Goddamn slimy (for supporting this abuse)

I expected better of you.

DAM, I don't even know what I can suggest you do. This is a hugely
hurtful thing for Ian to do.


It sucks, because I did look up to you, Ian. I did respect your work,
and it literally pains me to find these words. As much as I disagreed, I
respected the fact you always had technical grounds.

Clearly such blatent politicking tarnishes that respect, and I'd imagine
this is becoming a popular point of view.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt




_
The Free Email with so much more!
=> http://www.MuchoMail.com <=


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302135306.52a6a...@m0005309.ppops.net

Re: Proposal - preserve freedom of choice of init systems

[Bdale Garbee]

Russ Allbery  writes:

> We all want there to be multiple implementations of standard, reasonable
> APIs so that we can choose software based on its merits and not because
> it's the only implementation of a useful interface.  We also all live in
> the real world where that doesn't always happen.  The work doesn't
> magically accomplish itself.  Someone has to care enough to make it
> happen.  If no one cares enough, then I think we need to recognize that
> maybe having multiple implementations isn't important enough to motivate
> anyone to volunteer to do it, and therefore we'll have to live without the
> benefits of having them.
>
> If that feels like an unacceptable outcome, well, I think the right
> reaction is to go do the work so that this outcome doesn't arise.

Thanks, Russ.  This is exactly how I feel, too.

Bdale


pgpcvHlsK63qt.pgp
Description: PGP signature

Re: Proposal - preserve freedom of choice of init systems

[Steve Langasek]

On Sun, Mar 02, 2014 at 08:22:14PM +, Matthew Vernon wrote:

> > > Second, Matthew's proposal explicitly doesn't change the TC decision, so
> > > I'm not even sure what you think would be aborted here.  It wouldn't have
> > > any effect on the choice of default.  It dictates in a top-down manner to
> > > individual developers how to do their work and undermines the flexibility
> > > of Debian contributors in ways that I think are unnecessary and a little
> > > condescending, and requires work be done without identifying anyone who is
> > > going to do the work, which is why I voted against it.  But it's not some
> > > sort of end-run around the previous decision.

> > The previous decision does say that it is replaced completely by the
> > text of such a position statement and I do note that the proposed GR
> > does, very carefully, not refer to systemd as the default.  It makes for
> > a clumsier construction, which when combined with the level of legal-ish
> > arguments being made here, makes me suspicious.

> Please don't read anything into the lack of mentioning systemd in my
> GR proposal. I in no way intend to undermine their decision that
> systemd is the default linux init for jessie. I thought "The TC's
> decision on the default init system for Linux in jessie stands
> undisturbed." was clear enough.

Given the ambiguity about whether this GR vacates the earlier TC decision, I
think it would be best to simply include in your GR text a statement that

  The Debian project reaffirms the decision of the TC to make systemd the
  default init system for jessie.

(Then I suppose if people don't actually want to reaffirm this, they can
propose amendments to the contrary; but AFAICS it's better to be explicit
here.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Tollef Fog Heen  writes:

> ]] Russ Allbery
> 
> > Second, Matthew's proposal explicitly doesn't change the TC decision, so
> > I'm not even sure what you think would be aborted here.  It wouldn't have
> > any effect on the choice of default.  It dictates in a top-down manner to
> > individual developers how to do their work and undermines the flexibility
> > of Debian contributors in ways that I think are unnecessary and a little
> > condescending, and requires work be done without identifying anyone who is
> > going to do the work, which is why I voted against it.  But it's not some
> > sort of end-run around the previous decision.
> 
> The previous decision does say that it is replaced completely by the
> text of such a position statement and I do note that the proposed GR
> does, very carefully, not refer to systemd as the default.  It makes for
> a clumsier construction, which when combined with the level of legal-ish
> arguments being made here, makes me suspicious.

Please don't read anything into the lack of mentioning systemd in my
GR proposal. I in no way intend to undermine their decision that
systemd is the default linux init for jessie. I thought "The TC's
decision on the default init system for Linux in jessie stands
undisturbed." was clear enough.

Regards,

Matthew 

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5ba9d82vwp@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Russ Allbery]

Matthew Vernon  writes:

> I wish to propose the following general resolution, and hereby call for
> seconds. I don't think further lengthy discussion of the issues is
> likely to be productive, and therefore hope we can bring this swiftly to
> a vote so that the project can state its mind on this important
> issue. The substantive text is that which was drafted for the purposes
> of the technical committee's vote (where they decided not to pass a
> resolution on the subject).

I sent this just now to the TC bug in response to a message from Colin,
but since this GR conversation has started, it's probably more useful here
instead.

In general, the TC has spent months talking about this, and I've said
rather more than my fair share on the topic, so I would rather let the
rest of the project have their turn and largely stay out of this GR
debate.  But I'm not sure that I ever coherently presented, in a single
message, my core argument against the text that Matthew has now proposed
as a GR.  That's what this message is.  I'm happy to discuss it,
particularly to clarify.  I'm going to try to limit my involvement in the
other branches of the debate, in part because I'm a bit burned out on the
whole conversation and in part because I think I've already said my peace.

Since, in my opinion, this question is all about how the project wants to
govern itself and how we want to handle assigning responsibility for work
that we think should happen, I will be very interested in general project
discussion and, if there are enough seconds, voting on this topic.  It's
possible that my impression of how the project should work is at odds with
the project as a whole, which would be a valuable course correction for
me.

Anyway, here it is, with a few minor edits upon re-reading it:

I want to reiterate here, since it's easy to lose in the long discussions,
that I completely agree with the sentiment.  I like the idea of
standardized services and interfaces, I like having the flexibility of
multiple implementations of those services and use that flexibility quite
a bit myself.  I would generally prefer for multiple implementations to be
possible in any case where there are multiple ways of going about
something.

However, I also don't think those principles were ever what this debate
was about.  I don't think we'll find much disagreement with those as
general principles.

The question that is before us is not whether we approve of standard
interfaces and multiple implementations.  Everyone who has spoken up on
this topic has indicated support for allowing multiple implementations of
standard interfaces.  Rather, the question that was before us was about
the error case.  When circumstances arise where those multiple
implementations do not exist, who bears the burden of creating them?

The position of loose coupling is that the Debian contributor who wants to
package a piece of software is responsible for porting it to every major
init system.

The position for which I was advocating is that the people who are
interested in having software run on the non-default init system, which
*may* include the Debian contributor who is packaging it but *might not*,
are responsible for the porting work, and that packaging of the software
for Debian should not necessarily block on that work being completed.

In other words, I'm advocating the same position that we have right now
for translations: the package maintainer is not expected to translate
their package to other languages, but they are expected to incorporate
translations as they are made available.  The translators bear the burden
of the work for doing the translation, and if no one steps up to translate
a particular package to some language, it won't be available in that
language.

To take the specific example of GNOME, in a world in which there are
multiple implementations of logind that satisfy the same interface, there
is no conflict here.  I want to keep reiterating that, since it seems like
people keep thinking they're at war with others when no actual conflict
exists.  The GNOME maintainers have already said they'd be happy to allow
alternative dependencies, the systemd maintainers have already said they'd
be happy to work with the providers of alternative logind implementations
to sort out the proper dependency and package structure, GNOME upstream
has said that they'd be delighted for such a thing to exist, and everyone
would be happy to have this in place by jessie.  We're all a big happy
family on this point, even if some of the people in the back seat can't
stop poking each other.  :)

*All* of this argument is over what happens when those multiple
implementations don't actually materialize.

My continued objections to loose coupling is that I think it makes the
wrong choice in that contingency, and I think it does so in a way that's
destructive to Debian as a project.  I believe the loose coupling proposal
has the effect of trying to force Debian contributors to care abou

Re: Proposal - preserve freedom of choice of init systems

[Paul Tagliamonte]

On Sun, Mar 02, 2014 at 10:42:56AM -0800, Russ Allbery wrote:
> I think you're overreacting.

After some cool-off, I agree.

DAM, please disregard my messages. Sorry.

I'm still displeased at the reading of the language, but it's clear this isn't
a blatent abuse.

Sorry, Ian. I overreated.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Tollef Fog Heen]

]] Russ Allbery

(Dropped DAM and personal Ccs)

> Second, Matthew's proposal explicitly doesn't change the TC decision, so
> I'm not even sure what you think would be aborted here.  It wouldn't have
> any effect on the choice of default.  It dictates in a top-down manner to
> individual developers how to do their work and undermines the flexibility
> of Debian contributors in ways that I think are unnecessary and a little
> condescending, and requires work be done without identifying anyone who is
> going to do the work, which is why I voted against it.  But it's not some
> sort of end-run around the previous decision.

The previous decision does say that it is replaced completely by the
text of such a position statement and I do note that the proposed GR
does, very carefully, not refer to systemd as the default.  It makes for
a clumsier construction, which when combined with the level of legal-ish
arguments being made here, makes me suspicious.

It feels like we're way past rough consensus and working code and
running at full speed into a courtroom.

> Third, even if it were, as Andreas points out, we put that clause in there
> intentionally.  If the project wants to change the decision about the
> default init system, it can do so with a 1:1 majority.

I don't think anybody has a problem with the non-cornercase
interpretations of the GR.

> I think the way this GR is phrased is odd, and I agree with Bdale that I
> see no reason why it couldn't just be a straight statement on issues of
> the day without being attached to a TC decision.  Currently, it's attached
> to a decision about the default init system while not actually saying
> anything about the default init system, which I think is strange.  I
> concur with Kurt that while procedurally this may be allowed, I don't
> think it's a particularly good idea.

I think it's a terrible idea.  Ian writes that he specificially made it
as broad as he did in order to create this situation so that anything
could be included.

> Also, separately, please don't attack Ian for things that Matthew
> proposed, or for clauses in previous decision that Bdale drafted in
> conjunction with the project secretary.  This is not a situation of Ian's
> creation.

https://lists.debian.org/debian-vote/2014/03/msg00020.html, by Ian:

  That GR override clause was written by me.  I specifically drew it
  widely precisely so that, amongst other things, a GR could answer
  questions that the TC has failed to answer.

I don't think pointing at Ian for the clause is particularly unfair.
Ian's also seconded the proposed GR, which generally means you agree
with whatever you're seconding.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhws1kp7@xoog.err.no

Re: Proposal - preserve freedom of choice of init systems

[Russ Allbery]

Paul Tagliamonte  writes:
> On Sun, Mar 02, 2014 at 11:16:57AM -0700, Bdale Garbee wrote:

>> The part I don't understand is why reference is made to any TC decision
>> at all.  Unless the objectives include overturning the decision on the
>> default Linux init system for jessie, I see no reason to invoke the GR
>> clause in that resolution at all.

>> Why isn't this just a standalone GR asserting a "position statement
>> about issues of the day" on the coupling question?

> Ian's backdoor would then trigger and abort the TC decision, so he says.

I think you're overreacting.

First, there appears to be a general consensus on the TC (at least, I
recall Steve, Bdale, Ian, and I have all saying things along these lines
and while Andreas had some concerns about the margin, didn't seem to
disagree in principle, and I don't recall anyone else disagreeing) that
the TC should be overridable by a 1:1 project majority in general.

Now, I think one can make a good argument that it's one thing to override
a decision, and another thing to override a decision not to make technical
policy to make technical policy via GR, which would normally require a 2:1
majority.  I think a GR is a poor way to make specific technical policy,
as opposed to deciding on broad outcomes, so I'm not as happy about that.
But it's certainly not some radical idea or a significant deviation from
what we've already been talking about.

Second, Matthew's proposal explicitly doesn't change the TC decision, so
I'm not even sure what you think would be aborted here.  It wouldn't have
any effect on the choice of default.  It dictates in a top-down manner to
individual developers how to do their work and undermines the flexibility
of Debian contributors in ways that I think are unnecessary and a little
condescending, and requires work be done without identifying anyone who is
going to do the work, which is why I voted against it.  But it's not some
sort of end-run around the previous decision.

Third, even if it were, as Andreas points out, we put that clause in there
intentionally.  If the project wants to change the decision about the
default init system, it can do so with a 1:1 majority.

I think the way this GR is phrased is odd, and I agree with Bdale that I
see no reason why it couldn't just be a straight statement on issues of
the day without being attached to a TC decision.  Currently, it's attached
to a decision about the default init system while not actually saying
anything about the default init system, which I think is strange.  I
concur with Kurt that while procedurally this may be allowed, I don't
think it's a particularly good idea.

But I also don't think it really matters.  I think the proposal is a bad
idea, but I don't think trying to argue about supermajorities is the way
to point out that's a bad idea.  If a majority of the project disagrees
with me that it's a bad idea, that quite likely means that I'm wrong and
haven't thought through some aspect of the problem that makes it a better
idea than it appears to be to me.

Also, separately, please don't attack Ian for things that Matthew
proposed, or for clauses in previous decision that Bdale drafted in
conjunction with the project secretary.  This is not a situation of Ian's
creation.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tykigr3@windlord.stanford.edu

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Iain Lane (la...@debian.org) [140302 19:28]:
> The rest of the discussion notwithstanding, where do you think that
> 
> On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> > […]  
> > That doesn't contradict the GR.  If the GR passes we have two
> > resolutions:
> > 
> >  11th Feb as modified by GR: sysvinit as default, loose coupling
>
> 
> sysvinit comes from?

I think a qualified spelling error, and should read as "systemd as
default, loose coupling".



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302184104.gw16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > There is also this decision of the CTTE:
> > 
> >The TC chooses to not pass a resolution at the current time
> >about whether software may require specific init systems.
> > 
> > Which doesn't have this GR rider text in it, and is on the same
> > subject as this GR.
> 
> That doesn't contradict the GR.  If the GR passes we have two
> resolutions:
> 
>  11th Feb as modified by GR: sysvinit as default, loose coupling

The result of that CT decision is that systemd is the default.
The intend of this GR is not to change the default.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302183150.ga12...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Paul Tagliamonte]

On Sun, Mar 02, 2014 at 07:21:34PM +0100, Andreas Barth wrote:
> 1. the proposed GR doesn't overturn TCs decision about the default
> Linux init system, but holds that one up and adds something about
> loose coupling of init systems and packages[1]

The fact it has to be stated explicitly is insane.

> 2. the possibility to overturn TCs decision was inserted *by*
> *purpose* with our the common understanding of all TC members that if
> the developers together want to overturn our decision they should be
> able to do so with normal (1:1) majority. This was part of the
> proposals with systemd as Linux default and also with upstart as Linux
> default.

... when a GR is proposed on that subject.

> I need to summarize your mails on "useless escalation" which I don't
> consider helpful. Sorry.

Your point of view is noted.


However, confirming the interpretation of any GR which mentions the word
init as vacating the default init TC decision is nuts. This would be a position
statement about coupling, not default init, and it seems that this is to
be interpreted as triggering the clause, as noted by it's author.

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Iain Lane]

The rest of the discussion notwithstanding, where do you think that

On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> […]  
> That doesn't contradict the GR.  If the GR passes we have two
> resolutions:
> 
>  11th Feb as modified by GR: sysvinit as default, loose coupling
   

sysvinit comes from?

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Bdale Garbee (bd...@gag.com) [140302 19:17]:
> Colin Watson  writes:
> 
> > On Sun, Mar 02, 2014 at 12:49:22PM -0500, Paul Tagliamonte wrote:
> >> On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> >> > As a consequence, the GR replaces the outcome of the TC vote.  The GR
> >> > text explicitly adopts the existing TC decision on the default, and
> >> > adds to it.
> > [...]
> >>   2) Dishonest (using an unrelated GR to turn over the default init
> >>  decision made through a backdoor you put in)
> >
> > Huh?  Ian explicitly says, as does the text itself, that this proposed
> > GR *adopts* the TC decision on the default init system.  It doesn't
> > overturn it.
> 
> The part I don't understand is why reference is made to any TC decision
> at all.  Unless the objectives include overturning the decision on the
> default Linux init system for jessie, I see no reason to invoke the GR
> clause in that resolution at all.
> 
> Why isn't this just a standalone GR asserting a "position statement
> about issues of the day" on the coupling question?

I mostly agree on that (and would prefer to see it that way). With the
small exception that it would be good to explicitly state that this
position statement doesn't invoke the auto-nuke clause of our
decision.



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302182235.gv16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Paul Tagliamonte (paul...@debian.org) [140302 19:02]:
> On Sun, Mar 02, 2014 at 05:55:14PM +, Colin Watson wrote:
> > Huh?  Ian explicitly says, as does the text itself, that this proposed
> > GR *adopts* the TC decision on the default init system.  It doesn't
> > overturn it.
> 
> The fact there's a backdoor that was inserted that allowed him to
> overturn the TC decision with a GR that mentions the word init is
> absurd.

I don't know what you try to make about, but 

1. the proposed GR doesn't overturn TCs decision about the default
Linux init system, but holds that one up and adds something about
loose coupling of init systems and packages[1]

2. the possibility to overturn TCs decision was inserted *by*
*purpose* with our the common understanding of all TC members that if
the developers together want to overturn our decision they should be
able to do so with normal (1:1) majority. This was part of the
proposals with systemd as Linux default and also with upstart as Linux
default.


[1] whether you think that's a good idea is something else, but this
was not part by the TCs decision of the default Linux system, and the
TC decided later on to not make a decision about that (yet). So I fear
I need to summarize your mails on "useless escalation" which I don't
consider helpful. Sorry.


Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302182134.gu16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Paul Tagliamonte]

On Sun, Mar 02, 2014 at 11:16:57AM -0700, Bdale Garbee wrote:
> The part I don't understand is why reference is made to any TC decision
> at all.  Unless the objectives include overturning the decision on the
> default Linux init system for jessie, I see no reason to invoke the GR
> clause in that resolution at all.
> 
> Why isn't this just a standalone GR asserting a "position statement
> about issues of the day" on the coupling question?

Ian's backdoor would then trigger and abort the TC decision, so he says.

> Bdale

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Bdale Garbee]

Colin Watson  writes:

> On Sun, Mar 02, 2014 at 12:49:22PM -0500, Paul Tagliamonte wrote:
>> On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
>> > As a consequence, the GR replaces the outcome of the TC vote.  The GR
>> > text explicitly adopts the existing TC decision on the default, and
>> > adds to it.
> [...]
>>   2) Dishonest (using an unrelated GR to turn over the default init
>>  decision made through a backdoor you put in)
>
> Huh?  Ian explicitly says, as does the text itself, that this proposed
> GR *adopts* the TC decision on the default init system.  It doesn't
> overturn it.

The part I don't understand is why reference is made to any TC decision
at all.  Unless the objectives include overturning the decision on the
default Linux init system for jessie, I see no reason to invoke the GR
clause in that resolution at all.

Why isn't this just a standalone GR asserting a "position statement
about issues of the day" on the coupling question?

Bdale


pgp2Miww265xW.pgp
Description: PGP signature

Re: Proposal - preserve freedom of choice of init systems

[Paul Tagliamonte]

On Sun, Mar 02, 2014 at 05:55:14PM +, Colin Watson wrote:
> Huh?  Ian explicitly says, as does the text itself, that this proposed
> GR *adopts* the TC decision on the default init system.  It doesn't
> overturn it.

The fact there's a backdoor that was inserted that allowed him to
overturn the TC decision with a GR that mentions the word init is
absurd.

> -- 
> Colin Watson   [cjwat...@debian.org]


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Colin Watson]

On Sun, Mar 02, 2014 at 12:49:22PM -0500, Paul Tagliamonte wrote:
> On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> > As a consequence, the GR replaces the outcome of the TC vote.  The GR
> > text explicitly adopts the existing TC decision on the default, and
> > adds to it.
[...]
>   2) Dishonest (using an unrelated GR to turn over the default init
>  decision made through a backdoor you put in)

Huh?  Ian explicitly says, as does the text itself, that this proposed
GR *adopts* the TC decision on the default init system.  It doesn't
overturn it.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302175512.ga12...@riva.ucam.org

Re: Proposal - preserve freedom of choice of init systems

[Paul Tagliamonte]

On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > > If you're going to say we need to replace "the TC resolution is
> > > amended" with something like "we wish that instead the TC had decided
> > > blah", then please reconsider.  That would force the GR to avoid
> > > saying what its own effect is, which is unnecessarily confusing.
> > > Also, writing that text is very cumbersome.
> > 
> > The text currently says it's using the TC's power to decide
> > something, and so would fall under 4.1.4.  I think the intent of
> > this GR is not to override the TC's decision about the default, so
> > I'm currently not sure what to suggest.
> 
> The TC decision of the 11th of February said:
> 
>   Should the project pass a General Resolution before the release of
>   "jessie" asserting a "position statement about issues of the day" on
>   init systems, that position replaces the outcome of this vote and is
>   adopted by the Technical Committee as its own decision.
> 
> This a GR proposal is a "position statement about issues of the day"
> (as it says in the "Notes and rubric".)  It's on the subject of init
> systems.  Therefore it is covered by this wording.
> 
> As a consequence, the GR replaces the outcome of the TC vote.  The GR
> text explicitly adopts the existing TC decision on the default, and
> adds to it.

Ian, I'm extremely disaspointed in this childish behavior of trying to
insert a malicious trap-door to a decision.

I'm *EXTREMELY* disaspointed in this.

I'm CC'ing DAM.

This is, at minimum:

  1) A abuse of power (inserting a backdoor in a decision)
  2) Dishonest (using an unrelated GR to turn over the default init
 decision made through a backdoor you put in)
  3) Goddamn slimy (for supporting this abuse)

I expected better of you.

DAM, I don't even know what I can suggest you do. This is a hugely
hurtful thing for Ian to do.


It sucks, because I did look up to you, Ian. I did respect your work,
and it literally pains me to find these words. As much as I disagreed, I
respected the fact you always had technical grounds.

Clearly such blatent politicking tarnishes that respect, and I'd imagine
this is becoming a popular point of view.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Matthew Vernon (matth...@chiark.greenend.org.uk) [140302 17:41]:
> Andreas Barth  writes:
> 
> > Thanks for the reference to the auto-nuke clause in the TC decision.
> > How about adding something along the lines "To avoid any doubt, this
> > decision does not replace the TC resolution" to avoid invoking that
> > clause and keep the current decision (because that is also what this
> > proposal wants to achive)?
> 
> I thought my original text was reasonably clear that it wasn't seeking
> to change the default init system for jessie...?

It looks to me as the secretary doesn't fully agree with that, so
perhaps some extra clarifiaction. But well, as long as we manage to
have a common understanding what your text means it's ok for me.


Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302174357.gt16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Andrey Rahmatullin]

On Sun, Mar 02, 2014 at 01:07:00PM +, Ian Jackson wrote:
> > I understand your point.  But it feels to me like an abuse of the
> > CTs decision because it's on a related but different subject.  I
> > would prefer that it would just make a position statement that
> > doesn't have an effect on the CTs decision.
> 
> I don't think it's an abuse.  That GR override clause was written by
> me.  I specifically drew it widely precisely so that, amongst other
> things, a GR could answer questions that the TC has failed to answer.
> 
> Surely the question is simply whether this GR is indeed "on init
> systems".  Clearly it is.  Therefore the GR rider is engaged.

On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> > There is also this decision of the CTTE:
> > 
> >The TC chooses to not pass a resolution at the current time
> >about whether software may require specific init systems.
> > 
> > Which doesn't have this GR rider text in it, and is on the same
> > subject as this GR.
> 
> That doesn't contradict the GR.  If the GR passes we have two
> resolutions:
> 
>  11th Feb as modified by GR: sysvinit as default, loose coupling
>  28th Feb "we choose not to pass a resolution at the current time
>[ie on the 28th of February] about coupling"
> 
> These are not contradictory.  In particular, the 28th of February
> resolution should not be read as vacating the 11th of February
> resolution's GR rider, which is what you are suggesting.

Congratulations, that is a nice backdoor that nobody noticed on the code
review. We hope the backdoor will be fixed ASAP, the appropriate security
measures will be added and the intruder will be punished appropriately.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

Kurt Roeckx  writes:

> This might have as affect that the ctte's decision about the
> default is replaced by the result of the GR, and since this GR
> doesn't want to set the default currently it might result in not
> having a decision about the default.

I think given my current text says "The TC's decision on the default
init system for Linux in jessie stands undisturbed." this is an
unlikely outcome.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5beh2k35v4@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Hi,

Stuart Prescott  writes:

> Your rationale does not explain how the normal policy process has failed to 
> deliver the outcomes required by the project. I think the project should 

Sorry about that; I rather thought that the TC failing to rule on the
issue was failing to provide clarity on this important issue.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5biorw35xo@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

Andreas Barth  writes:

> Thanks for the reference to the auto-nuke clause in the TC decision.
> How about adding something along the lines "To avoid any doubt, this
> decision does not replace the TC resolution" to avoid invoking that
> clause and keep the current decision (because that is also what this
> proposal wants to achive)?

I thought my original text was reasonably clear that it wasn't seeking
to change the default init system for jessie...?
 
Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5bmwh83655@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > There is also this decision of the CTTE:
> > 
> >The TC chooses to not pass a resolution at the current time
> >about whether software may require specific init systems.
> > 
> > Which doesn't have this GR rider text in it, and is on the same
> > subject as this GR.
> 
> That doesn't contradict the GR.  If the GR passes we have two
> resolutions:
> 
>  11th Feb as modified by GR: sysvinit as default, loose coupling
>  28th Feb "we choose not to pass a resolution at the current time
>[ie on the 28th of February] about coupling"
> 
> These are not contradictory.  In particular, the 28th of February
> resolution should not be read as vacating the 11th of February
> resolution's GR rider, which is what you are suggesting.

I'm not disagreeing that you're allowed to do it, I'm disagreeing
that it's a good idea to do it.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302151034.ga7...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> There is also this decision of the CTTE:
> 
>The TC chooses to not pass a resolution at the current time
>about whether software may require specific init systems.
> 
> Which doesn't have this GR rider text in it, and is on the same
> subject as this GR.

That doesn't contradict the GR.  If the GR passes we have two
resolutions:

 11th Feb as modified by GR: sysvinit as default, loose coupling
 28th Feb "we choose not to pass a resolution at the current time
   [ie on the 28th of February] about coupling"

These are not contradictory.  In particular, the 28th of February
resolution should not be read as vacating the 11th of February
resolution's GR rider, which is what you are suggesting.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21267.17688.624142.684...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 01:07:00PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote:
> > > Putting the "notes and rubric" section first might make this clearer
> > > for you to see, but it would make the whole GR text much less clear to
> > > read because it would start with several paragraphs of procedural
> > > palaver.
> > 
> > I understand your point.  But it feels to me like an abuse of the
> > CTs decision because it's on a related but different subject.  I
> > would prefer that it would just make a position statement that
> > doesn't have an effect on the CTs decision.
> 
> I don't think it's an abuse.  That GR override clause was written by
> me.  I specifically drew it widely precisely so that, amongst other
> things, a GR could answer questions that the TC has failed to answer.
> 
> Surely the question is simply whether this GR is indeed "on init
> systems".  Clearly it is.  Therefore the GR rider is engaged.

There is also this decision of the CTTE:

   The TC chooses to not pass a resolution at the current time
   about whether software may require specific init systems.

Which doesn't have this GR rider text in it, and is on the same
subject as this GR.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302133723.ga5...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[NoTo CTTE]

He has a right to call a GR.
You are trying your hardest to make sure systemd is the
only choice for all linux systems, all major linux distros,
and if we don't like it we can "go use MacOSX or BSD" or
"roll your own distro".

The fact is that SysV works NOW. The scripts work and 
are stable and are FINE.

The changing of the init system out into some huge octopus
of a secondary OS under the kernel was NOT and _IS_ not
a proper decision for the technical committie to make,
just as changing from the linux kernel to some other 
kernel would be improper for that venue.

This is a psyops.
Systemd has won not by merit but by force and politics.
It is a gargantuan 200k line unaudited mess running
as with full privledges.

Concurrent boot allready exists in sysv, and is as
easy as writing a shell script with & between each command
within each set of commands needed to start 
concurrently.

bla & bla & bla;
blu & blu & blu & blu;
etc

I program 3d, 2d, and text console programs for linux etc.
I make 3d architectual maps, models, music, textures, and so on.
I do enough. The linux I like exists right now, and has for years.

You do NOT have the right to tell me to go roll my own.
You do NOT have the right to take linux from me or anyone else
who actually does work.
AND YOU DO NOT have the right to go tell us to roll our own
when what we like allready EXISTS NOW.

You people need to be stopped. By any means necessary.
Linux IS about choice. You are extinguishing that choice.
This is political.

The man has a right to his GR. You have NO right to pressure
him into not calling it.

Call the GR officially please.





In Respose To:

Hi Matthew,

Your rationale does not explain how the normal policy process has failed to 
deliver the outcomes required by the project. I think the project should 
require a very clear explanation as to why it should interfere in this 
process. At least one policy editor and the relevant maintainers have 
already been working on this and the process is in no way deadlocked. Given 
that, I can't see any reason why this work should be disrupted. 

If you do have a rationale for pressing forward on this GR, then you should 
also note that the wording in this proposed resolution is poorly constructed 
quite simply because some of the issues that are very clearly articulated in 
#727708 have been ignored [0]. 

The worst problem is that the particular wording here fails the "someone 
should do something" test -- that's not how Debian or Free Software works at 
all. If no-one has a particular itch to actually sit down and write an 
alternative implementation, then the work doesn't get done. Demanding, as 
the proposed text does, that some future and unnamed group of people must do 
some work is doomed. At least the absence of volunteers to declassify 
debian-private mails doesn't make packages RC buggy.

Perhaps all our energies would be better spent fixing real bugs rather than 
arguing about hypothetical ones? It would be disappointing for us to waste 
yet more time and energy on this matter rather than actually concentrating 
on making a great release. Feel free to pick any of the 300ish RC bugs in 
jessie if you need some suggestions.

Stuart

[0] And I don't think it's unreasonable to assume that the proposers of GRs 
on this issue would have read this information carefully.


_
The Free Email with so much more!
=> http://www.MuchoMail.com <=


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302051229.52a77...@m0005310.ppops.net

Re: Proposal - preserve freedom of choice of init systems

[NoTo CTTE]

He has a right to call a GR.You are trying your hardest to make sure systemd is theonly choice for all linux systems, all major linux distros,and if we don't like it we can "go use MacOSX or BSD" or"roll your own distro".The fact is that SysV works NOW. The scripts work and are stable and are FINE.The changing of the init system out into some huge octopusof a secondary OS under the kernel was NOT and _IS_ nota proper decision for the technical committie to make,just as changing from the linux kernel to some other kernel would be improper for that venue.This is a psyops.Systemd has won not by merit but by force and politics.It is a gargantuan 200k line unaudited mess runningas with full privledges.Concurrent boot allready exists in sysv, and is aseasy as writing a shell script with & between each commandwithin each set of commands needed to start concurrently.bla & bla & bla;blu & blu & blu & blu;etcI program 3d, 2d, and text console programs for linux etc.I make 3d architectual maps, models, music, textures, and so on.I do enough. The linux I like exists right now, and has for years.You do NOT have the right to tell me to go roll my own.You do NOT have the right to take linux from me or anyone elsewho actually does work.AND YOU DO NOT have the right to go tell us to roll our ownwhen what we like allready EXISTS NOW.You people need to be stopped. By any means necessary.Linux IS about choice. You are extinguishing that choice.This is political.The man has a right to his GR. You have NO right to pressurehim into not calling it.Call the GR officially please.In Respose To:Hi Matthew,Your rationale does not explain how the normal policy process has failed to deliver the outcomes required by the project. I think the project should require a very clear explanation as to why it should interfere in this process. At least one policy editor and the relevant maintainers have already been working on this and the process is in no way deadlocked. Given that, I can't see any reason why this work should be disrupted. If you do have a rationale for pressing forward on this GR, then you should also note that the wording in this proposed resolution is poorly constructed quite simply because some of the issues that are very clearly articulated in #727708 have been ignored [0]. The worst problem is that the particular wording here fails the "someone should do something" test -- that's not how Debian or Free Software works at all. If no-one has a particular itch to actually sit down and write an alternative implementation, then the work doesn't get done. Demanding, as the proposed text does, that some future and unnamed group of people must do some work is doomed. At least the absence of volunteers to declassify debian-private mails doesn't make packages RC buggy.Perhaps all our energies would be better spent fixing real bugs rather than arguing about hypothetical ones? It would be disappointing for us to waste yet more time and energy on this matter rather than actually concentrating on making a great release. Feel free to pick any of the 300ish RC bugs in jessie if you need some suggestions.Stuart[0] And I don't think it's unreasonable to assume that the proposers of GRs on this issue would have read this information carefully. The Free Email with so much more!=> http://www.MuchoMail.com <=

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote:
> > Putting the "notes and rubric" section first might make this clearer
> > for you to see, but it would make the whole GR text much less clear to
> > read because it would start with several paragraphs of procedural
> > palaver.
> 
> I understand your point.  But it feels to me like an abuse of the
> CTs decision because it's on a related but different subject.  I
> would prefer that it would just make a position statement that
> doesn't have an effect on the CTs decision.

I don't think it's an abuse.  That GR override clause was written by
me.  I specifically drew it widely precisely so that, amongst other
things, a GR could answer questions that the TC has failed to answer.

Surely the question is simply whether this GR is indeed "on init
systems".  Clearly it is.  Therefore the GR rider is engaged.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21267.11508.700159.261...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> > > This a GR proposal is a "position statement about issues of the day"
> > > (as it says in the "Notes and rubric".)  It's on the subject of init
> > > systems.  Therefore it is covered by this wording.
> > 
> > But it also says:
> > 1. Exercise of the TC's power to set policy
> > 
> >   For jessie and later releases, the TC's power to set technical
> >   policy (Constitution 6.1.1) is exercised as follows:
> 
> Yes.  That is part of the text which is added to the TC decision of
> the 11th of February, by virtue of the GR override clause in that
> decision.  As the rubric says, s1 and s2 of the GR text are added to
> that TC decision text.  s1 of the GR text is not freestanding.
> 
> Putting the "notes and rubric" section first might make this clearer
> for you to see, but it would make the whole GR text much less clear to
> read because it would start with several paragraphs of procedural
> palaver.

I understand your point.  But it feels to me like an abuse of the
CTs decision because it's on a related but different subject.  I
would prefer that it would just make a position statement that
doesn't have an effect on the CTs decision.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302130248.ga5...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> > This a GR proposal is a "position statement about issues of the day"
> > (as it says in the "Notes and rubric".)  It's on the subject of init
> > systems.  Therefore it is covered by this wording.
> 
> But it also says:
> 1. Exercise of the TC's power to set policy
> 
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:

Yes.  That is part of the text which is added to the TC decision of
the 11th of February, by virtue of the GR override clause in that
decision.  As the rubric says, s1 and s2 of the GR text are added to
that TC decision text.  s1 of the GR text is not freestanding.

Putting the "notes and rubric" section first might make this clearer
for you to see, but it would make the whole GR text much less clear to
read because it would start with several paragraphs of procedural
palaver.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21267.10471.368835.213...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote:
> 
> This a GR proposal is a "position statement about issues of the day"
> (as it says in the "Notes and rubric".)  It's on the subject of init
> systems.  Therefore it is covered by this wording.

But it also says:
1. Exercise of the TC's power to set policy

  For jessie and later releases, the TC's power to set technical
  policy (Constitution 6.1.1) is exercised as follows:


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302124423.ga4...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > If you're going to say we need to replace "the TC resolution is
> > amended" with something like "we wish that instead the TC had decided
> > blah", then please reconsider.  That would force the GR to avoid
> > saying what its own effect is, which is unnecessarily confusing.
> > Also, writing that text is very cumbersome.
> 
> The text currently says it's using the TC's power to decide
> something, and so would fall under 4.1.4.  I think the intent of
> this GR is not to override the TC's decision about the default, so
> I'm currently not sure what to suggest.

The TC decision of the 11th of February said:

  Should the project pass a General Resolution before the release of
  "jessie" asserting a "position statement about issues of the day" on
  init systems, that position replaces the outcome of this vote and is
  adopted by the Technical Committee as its own decision.

This a GR proposal is a "position statement about issues of the day"
(as it says in the "Notes and rubric".)  It's on the subject of init
systems.  Therefore it is covered by this wording.

As a consequence, the GR replaces the outcome of the TC vote.  The GR
text explicitly adopts the existing TC decision on the default, and
adds to it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21267.9603.580687.25...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 01:06:46PM +0100, Andreas Barth wrote:
> * Kurt Roeckx (k...@roeckx.be) [140302 12:36]:
> > On Sun, Mar 02, 2014 at 12:26:38PM +0100, Andreas Barth wrote:
> > > * Kurt Roeckx (k...@roeckx.be) [140302 12:23]:
> > > > On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > > > > Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of 
> > > > > init systems"):
> > > > > > This is probably going to require a 2:1 majority requirement as
> > > > > > written.
> > > > > 
> > > > > Do you agree that the intent can be achieved by something requiring a
> > > > > 1:1 majority ?  If so, can you please say how.
> > > > > 
> > > > > If you're going to say we need to replace "the TC resolution is
> > > > > amended" with something like "we wish that instead the TC had decided
> > > > > blah", then please reconsider.  That would force the GR to avoid
> > > > > saying what its own effect is, which is unnecessarily confusing.
> > > > > Also, writing that text is very cumbersome.
> > > > 
> > > > The text currently says it's using the TC's power to decide
> > > > something, and so would fall under 4.1.4.  I think the intent of
> > > > this GR is not to override the TC's decision about the default, so
> > > > I'm currently not sure what to suggest.
> > > 
> > > I don't see why the text couldn't just say that the developers make a
> > > position statement. As per 4.1.5 this could be done with a
> > > 1:1-majority.
> > 
> > This might have as affect that the ctte's decision about the
> > default is replaced by the result of the GR, and since this GR
> > doesn't want to set the default currently it might result in not
> > having a decision about the default.
> 
> Thanks for the reference to the auto-nuke clause in the TC decision.
> How about adding something along the lines "To avoid any doubt, this
> decision does not replace the TC resolution" to avoid invoking that
> clause and keep the current decision (because that is also what this
> proposal wants to achive)?

I think that should work.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302121000.ga3...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Andreas Barth (a...@ayous.org) [140302 13:07]:
> Thanks for the reference to the auto-nuke clause in the TC decision.
> How about adding something along the lines "To avoid any doubt, this
> decision does not replace the TC resolution" to avoid invoking that
> clause and keep the current decision (because that is also what this
> proposal wants to achive)?

(and probably with "this position statement", because that is what it
is)



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302120820.gs16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Kurt Roeckx (k...@roeckx.be) [140302 12:36]:
> On Sun, Mar 02, 2014 at 12:26:38PM +0100, Andreas Barth wrote:
> > * Kurt Roeckx (k...@roeckx.be) [140302 12:23]:
> > > On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > > > Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> > > > systems"):
> > > > > This is probably going to require a 2:1 majority requirement as
> > > > > written.
> > > > 
> > > > Do you agree that the intent can be achieved by something requiring a
> > > > 1:1 majority ?  If so, can you please say how.
> > > > 
> > > > If you're going to say we need to replace "the TC resolution is
> > > > amended" with something like "we wish that instead the TC had decided
> > > > blah", then please reconsider.  That would force the GR to avoid
> > > > saying what its own effect is, which is unnecessarily confusing.
> > > > Also, writing that text is very cumbersome.
> > > 
> > > The text currently says it's using the TC's power to decide
> > > something, and so would fall under 4.1.4.  I think the intent of
> > > this GR is not to override the TC's decision about the default, so
> > > I'm currently not sure what to suggest.
> > 
> > I don't see why the text couldn't just say that the developers make a
> > position statement. As per 4.1.5 this could be done with a
> > 1:1-majority.
> 
> This might have as affect that the ctte's decision about the
> default is replaced by the result of the GR, and since this GR
> doesn't want to set the default currently it might result in not
> having a decision about the default.

Thanks for the reference to the auto-nuke clause in the TC decision.
How about adding something along the lines "To avoid any doubt, this
decision does not replace the TC resolution" to avoid invoking that
clause and keep the current decision (because that is also what this
proposal wants to achive)?



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302120646.gr16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Thibaut Paumard]

Hi,

Le 01/03/2014 00:45, Matthew Vernon a écrit :
> 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:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
> 
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
> 
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
> 
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.

I wonder whether this GR has the following corollary:

"Packages shipping services or daemons must ensure that such services
are started and stopped with the same defaults under the various init
systems."

This corollary itself means two things:

"Packages shipping services or daemons must continue shipping functional
Sys-V style RC scripts", which I think is good, and

"Packages shipping services or daemons must ship whatever is required to
start and stop said service by any init system introduced in Debian in
the past and future", which I think would be bad.

Also, is that OK for a package to Recommend a specific init system
rather that Depend on it?

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 12:26:38PM +0100, Andreas Barth wrote:
> * Kurt Roeckx (k...@roeckx.be) [140302 12:23]:
> > On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > > Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> > > systems"):
> > > > This is probably going to require a 2:1 majority requirement as
> > > > written.
> > > 
> > > Do you agree that the intent can be achieved by something requiring a
> > > 1:1 majority ?  If so, can you please say how.
> > > 
> > > If you're going to say we need to replace "the TC resolution is
> > > amended" with something like "we wish that instead the TC had decided
> > > blah", then please reconsider.  That would force the GR to avoid
> > > saying what its own effect is, which is unnecessarily confusing.
> > > Also, writing that text is very cumbersome.
> > 
> > The text currently says it's using the TC's power to decide
> > something, and so would fall under 4.1.4.  I think the intent of
> > this GR is not to override the TC's decision about the default, so
> > I'm currently not sure what to suggest.
> 
> I don't see why the text couldn't just say that the developers make a
> position statement. As per 4.1.5 this could be done with a
> 1:1-majority.

This might have as affect that the ctte's decision about the
default is replaced by the result of the GR, and since this GR
doesn't want to set the default currently it might result in not
having a decision about the default.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302113547.ga3...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Andreas Barth]

* Kurt Roeckx (k...@roeckx.be) [140302 12:23]:
> On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> > Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> > systems"):
> > > This is probably going to require a 2:1 majority requirement as
> > > written.
> > 
> > Do you agree that the intent can be achieved by something requiring a
> > 1:1 majority ?  If so, can you please say how.
> > 
> > If you're going to say we need to replace "the TC resolution is
> > amended" with something like "we wish that instead the TC had decided
> > blah", then please reconsider.  That would force the GR to avoid
> > saying what its own effect is, which is unnecessarily confusing.
> > Also, writing that text is very cumbersome.
> 
> The text currently says it's using the TC's power to decide
> something, and so would fall under 4.1.4.  I think the intent of
> this GR is not to override the TC's decision about the default, so
> I'm currently not sure what to suggest.


I don't see why the text couldn't just say that the developers make a
position statement. As per 4.1.5 this could be done with a
1:1-majority.



Andi


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302112638.gq16...@mails.so.argh.org

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
> systems"):
> > This is probably going to require a 2:1 majority requirement as
> > written.
> 
> Do you agree that the intent can be achieved by something requiring a
> 1:1 majority ?  If so, can you please say how.
> 
> If you're going to say we need to replace "the TC resolution is
> amended" with something like "we wish that instead the TC had decided
> blah", then please reconsider.  That would force the GR to avoid
> saying what its own effect is, which is unnecessarily confusing.
> Also, writing that text is very cumbersome.

The text currently says it's using the TC's power to decide
something, and so would fall under 4.1.4.  I think the intent of
this GR is not to override the TC's decision about the default, so
I'm currently not sure what to suggest.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302112246.ga2...@roeckx.be

Re: Proposal - preserve freedom of choice of init systems

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal - preserve freedom of choice of init 
systems"):
> This is probably going to require a 2:1 majority requirement as
> written.

Do you agree that the intent can be achieved by something requiring a
1:1 majority ?  If so, can you please say how.

If you're going to say we need to replace "the TC resolution is
amended" with something like "we wish that instead the TC had decided
blah", then please reconsider.  That would force the GR to avoid
saying what its own effect is, which is unnecessarily confusing.
Also, writing that text is very cumbersome.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21267.3964.32328.687...@chiark.greenend.org.uk

Re: Proposal - preserve freedom of choice of init systems

[Kurt Roeckx]

On Fri, Feb 28, 2014 at 11:45:01PM +, Matthew Vernon wrote:
> Hi,
> 
> I wish to propose the following general resolution, and hereby call
> for seconds. I don't think further lengthy discussion of the issues is
> likely to be productive, and therefore hope we can bring this swiftly
> to a vote so that the project can state its mind on this important
> issue. The substantive text is that which was drafted for the purposes
> of the technical committee's vote (where they decided not to pass a
> resolution on the subject).

This is probably going to require a 2:1 majority requirement as
written.


Kurt


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140301105155.ga1...@roeckx.be

Proposal - preserve freedom of choice of init systems

[Matthew Vernon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I wish to propose the following general resolution, and hereby call
for seconds. I don't think further lengthy discussion of the issues is
likely to be productive, and therefore hope we can bring this swiftly
to a vote so that the project can state its mind on this important
issue. The substantive text is that which was drafted for the purposes
of the technical committee's vote (where they decided not to pass a
resolution on the subject).

Regards,

Matthew

** Begin Proposal **

0. Rationale

  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 in Debian may depend on a particular init system.

  This GR seeks to preserve the freedom of our users now to select an
  init system of their choice, and the project's freedom to select a
  different init system in the future. It will avoid Debian becoming
  accidentally locked in to a particular init system (for example,
  because so much unrelated software has ended up depending on a
  particular init system that the burden of effort required to change
  init system becomes too great). A number of init systems exist, and
  it is clear that there is not yet broad consensus as to what the
  best init system might look like.

  This GR does not make any comment on the relative merits of
  different init systems; the technical committee has decided upon the
  default init system for Linux for jessie.

1. Exercise of the TC's power to set policy

  For jessie and later releases, the TC's power to set technical
  policy (Constitution 6.1.1) is exercised as follows:

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:

   * alternative init system implementations
   * special-use packages such as managers for init systems
   * cooperating groups of packages intended for use with specific init
 systems

  provided that these are not themselves required by other software
  whose main purpose is not the operation of a specific init system.

  Degraded operation with some init systems is tolerable, so long as
  the degradation is no worse than what the Debian project would
  consider a tolerable (non-RC) bug even if it were affecting all
  users.  So the lack of support for a particular init system does not
  excuse a bug nor reduce its severity; but conversely, nor is a bug
  more serious simply because it is an incompatibility of some software
  with some init system(s).

  Maintainers are encouraged to accept technically sound patches
  to enable improved interoperation with various init systems.

3. Notes and rubric

  This resolution is a Position Statement about Issues of the Day
  (Constitution 4.1.5), triggering the General Resolution override
  clause in the TC's resolution of the 11th of February.

  The TC's decision on the default init system for Linux in jessie
  stands undisturbed.

  However, the TC resolution is altered to add the additional text
  in sections (1) and (2) above.

** End Proposal **
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iQIVAwUBUxEfVhL00hyPamPIAQiO5RAArxBpu4ODM98hhqvV2u/KOQxMyWtD3pGf
gUXyf8solvuM0E7MTveLrwjr5NveeL7wSgspoRUdWapGqIYWFclj92tgUs4E3sP8
seuf/2h2CjZDbWEAebZ3jMCmgD+eBSAX5BXVm6sF0pRLrpdHX/qB4Ppvv7LHClc2
qj57MT2iju1WXQO9DvSx9JQCceozJcTxcKRSNr4oXnvRi5gmSKdhpRjzGo0TOsDZ
3etc7W8/nMD2oKplat9pU7ejezU80z35/nnPrx9JgRQrQ+r8pL4pYt2L2N43qM+b
AEaFwrz6lDudoGr6YlFMrm2QWEzeo+tF2/it5+5RrQCXSUAq1B10AU8Bjpo1y0wc
2EjMSDVldQch+n+OlzQt2EvCXxl4dGNHAWWtkmAXISvgNaycRJeogDTwFxfQVRuw
tIeQNSXrBaHU5id4il/LjWc3X8MTmgwlxGM5lOFIac2ozWTi7dJDrg/1YqmngNwt
fXFRsyDbWcosaQQyMsnfO+CTILT8qzTc2W6IRo0hoR8Od5T4ivVD4SvNDd5Xi2eK
+C8Vo6Mbyh89+Fj1yEiNUfKGrEcZCDVopcF/Y5k5x/XIt2+Kc18ELQOn2XZV8PnR
D47rMjs53E7B8gJSwnrTiiKo5NzjOE84ranr7dO6elGG9JPdZ3yOjDEsUeUj6+ko
ucVLwJaLR30=
=J+/m
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21265.8061.763642.6...@aragorn.weathertop.principate.org.uk