Bug#727708: [mjr.org] Re: Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie

[Tony Thedford]

It is just as I thought.. incompetence has taken control. Good luck with 
that.




On 02/19/2014 08:30 AM, Paul Hedderly wrote:

On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote:

On 02/18/2014 09:34 PM, Jason Frothingham wrote:

...


 Adopting systemd does not, in any way shape, form, idea, concept,
 conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
 etc. the goal of a computationally stable, bug-free, and flexible operating
 system.�



First of all, YES it does.. and a lot.. and the majority of competent Debian
users know this, and that is why you are catching so much hell over putting it

Since you must have spoken to "the majority of competant Debian users" to know 
this...

Could you write up a report of exactly what they said please it would be very
helpful. Or point to the report you read and "quoted"? If not, then stop with
the lies and the FUD.


into Debian. And this is why so many people are coming out of the woodwork to
express their concerns.. they are concerned about the integrity (stable,

You're the third. Perhaps you three the only "competant Debian users"?


bug-free, flexible) of Debian as a viable server and general purpose operating
system for critical applications.. and they don't want it screwed with!

You seem to think that you wont be able to chose not to use Systemd - so you've
not read very much of the debate or done much research. Here is a clue. Systemd
will never make it onto the non-linux ports, so there will always be at least
one other init available. You will always have a choice. And you could step up
to maintain more choice in Debian if you so desired rather than telling other
volunteers what to do. That is "the Debian way".


I have been "coding" since the early 80's, so please don't go there with me, it
doesn't work. I don't care about systemd's capabilities.. that is a mute point.

Perhaps you meant a moot point. A mute point would be very quiet indeed.
Lots of other people do care and have said so in this debate. I happen to be one
using a lot of the new features to great effect, on desktops. AND SERVERS.


All I need to know is that it is an overly complicated, unnecessary piece of
crapware that reduces the integrity of the distribution and that is all that
matters.

You have to specific or you'll be accused of FUD. Hand waving and shouting does
not count.
_Can_ you give more information on how it is overcomplicated?
Or unnecessary?
Or crap?
If not... quit with the lies and the FUD.


As to you initial question about what I would have the developers do.. I would
say do just that.. develop Debian software that continues to make it a truly
universal operating system and follows the original intent of the Debian way.

Could you quote what "the Debian way" is? Are you a DD involved in defining that
elusive thing?

For _me_ one part of Debian has always to excell in making amazing technology
and code available for everyone. Times have changed in twenty years. The linux
kernel is not the same as it was in 1991. Computers are not used in the same
static ways. Debian has to support a huge range of very dynamic systems now, and
sysV just does not cut it. Sure it works _ok_ on static environments - but 
Debian
supports far more than static servers.


Debian has been around almost as long as the Internet itself..

Debian was started in 1993. The internet... try about 1973. Yes Debian is half
the age of the internet. It is nearly as old as the Linux kernel, and not that 
much
younger than GNU, but your point is invalidated by lack of truth.


there are a lot
of users out here that don't want to see anyone mess it up! ..Figure out a way
around being stuck having to use udev since it has been co-opted by systemd..
that would be my first task for you!

If you don't want udev, then try Debian Potato. It might make you happy and will
forever have sysvinit. And please stop with the FUD and other trolling.

Regards






 On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford  wrote:

 Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
 would say! As to why there are developers within Debian who are
 hellbent on turning Debian into buggy desktop software rather than
 keeping with the universal operating system directive.. I will never
 know! Debian is a major force in global server software and therefore
 must remain extremely stable, bug-free, and flexible.. all of which
 systemd/gnome crapware nullifies!






--
Tony Thedford
Access Technologies
850 Belt Line Rd
Garland, TX 75040
Phone: 972.414.8356
Email: t...@accesslab.com


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53058842.9050...@accesslab.com

Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie

[Paul Hedderly]

On Wed, Feb 19, 2014 at 01:51:56AM -0600, Tony Thedford wrote:
> 
> On 02/18/2014 09:34 PM, Jason Frothingham wrote:
> 
> ...
> 
> 
> Adopting systemd does not, in any way shape, form, idea, concept,
> conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
> etc. the goal of a computationally stable, bug-free, and flexible 
> operating
> system.�
> 
> 
> 
> First of all, YES it does.. and a lot.. and the majority of competent Debian
> users know this, and that is why you are catching so much hell over putting it

Since you must have spoken to "the majority of competant Debian users" to know 
this...

Could you write up a report of exactly what they said please it would be very
helpful. Or point to the report you read and "quoted"? If not, then stop with
the lies and the FUD.

> into Debian. And this is why so many people are coming out of the woodwork to
> express their concerns.. they are concerned about the integrity (stable,

You're the third. Perhaps you three the only "competant Debian users"?

> bug-free, flexible) of Debian as a viable server and general purpose operating
> system for critical applications.. and they don't want it screwed with!

You seem to think that you wont be able to chose not to use Systemd - so you've
not read very much of the debate or done much research. Here is a clue. Systemd
will never make it onto the non-linux ports, so there will always be at least
one other init available. You will always have a choice. And you could step up
to maintain more choice in Debian if you so desired rather than telling other
volunteers what to do. That is "the Debian way".

> I have been "coding" since the early 80's, so please don't go there with me, 
> it
> doesn't work. I don't care about systemd's capabilities.. that is a mute 
> point.

Perhaps you meant a moot point. A mute point would be very quiet indeed.
Lots of other people do care and have said so in this debate. I happen to be one
using a lot of the new features to great effect, on desktops. AND SERVERS.

> All I need to know is that it is an overly complicated, unnecessary piece of
> crapware that reduces the integrity of the distribution and that is all that
> matters.

You have to specific or you'll be accused of FUD. Hand waving and shouting does
not count.
_Can_ you give more information on how it is overcomplicated?
Or unnecessary?
Or crap?
If not... quit with the lies and the FUD.

> As to you initial question about what I would have the developers do.. I would
> say do just that.. develop Debian software that continues to make it a truly
> universal operating system and follows the original intent of the Debian way.

Could you quote what "the Debian way" is? Are you a DD involved in defining that
elusive thing?

For _me_ one part of Debian has always to excell in making amazing technology
and code available for everyone. Times have changed in twenty years. The linux
kernel is not the same as it was in 1991. Computers are not used in the same
static ways. Debian has to support a huge range of very dynamic systems now, and
sysV just does not cut it. Sure it works _ok_ on static environments - but 
Debian
supports far more than static servers.

> Debian has been around almost as long as the Internet itself..

Debian was started in 1993. The internet... try about 1973. Yes Debian is half
the age of the internet. It is nearly as old as the Linux kernel, and not that 
much
younger than GNU, but your point is invalidated by lack of truth.

> there are a lot
> of users out here that don't want to see anyone mess it up! ..Figure out a way
> around being stuck having to use udev since it has been co-opted by systemd..
> that would be my first task for you!

If you don't want udev, then try Debian Potato. It might make you happy and will
forever have sysvinit. And please stop with the FUD and other trolling.

Regards

> 
> 
> 
> 
> 
> On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford  wrote:
> 
> Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
> would say! As to why there are developers within Debian who are
> hellbent on turning Debian into buggy desktop software rather than
> keeping with the universal operating system directive.. I will never
> know! Debian is a major force in global server software and therefore
> must remain extremely stable, bug-free, and flexible.. all of which
> systemd/gnome crapware nullifies!
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Tony Thedford
> Access Technologies
> 850 Belt Line Rd
> Garland, TX 75040
> Phone: 972.414.8356
> Email: t...@accesslab.com
> 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219143034.go16...@wacka.mjr.org

Bug#727708: [gmail.com] Re: Bug#727708: call for votes on default Linux init system for jessie

[Tony Thedford]

On 02/18/2014 09:34 PM, Jason Frothingham wrote:

...

Adopting systemd does not, in any way shape, form, idea, concept, 
conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. 
etc. etc. the goal of a computationally stable, bug-free, and flexible 
operating system.�




First of all, YES it does.. and a lot.. and the majority of competent 
Debian users know this, and that is why you are catching so much hell 
over putting it into Debian. And this is why so many people are coming 
out of the woodwork to express their concerns.. they are concerned about 
the integrity (stable, bug-free, flexible) of Debian as a viable server 
and general purpose operating system for critical applications.. and 
they don't want it screwed with!



So do this, and other mailing lists a favor, knock off the Fear, 
Uncertainty, and Doubt. �if you have the coding chops to actually 
comment on systemd's capabilities and features; or lack-thereof; at a 
code level rather than just at a Moronix Level, you'd probably be 
better off diving in and fixing bugs yourself.�




I have been "coding" since the early 80's, so please don't go there with 
me, it doesn't work. I don't care about systemd's capabilities.. that is 
a mute point. All I need to know is that it is an overly complicated, 
unnecessary piece of crapware that reduces the integrity of the 
distribution and that is all that matters.



As to you initial question about what I would have the developers do.. I 
would say do just that.. develop Debian software that continues to make 
it a truly universal operating system and follows the original intent of 
the Debian way. Debian has been around almost as long as the Internet 
itself.. there are a lot of users out here that don't want to see anyone 
mess it up! ..Figure out a way around being stuck having to use udev 
since it has been co-opted by systemd.. that would be my first task for you!






On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford > wrote:


Putting the "systemd" issue on bugs.debian.org
 is a bit ridiculous I would say! As to
why there are developers within Debian who are hellbent on turning
Debian into buggy desktop software rather than keeping with the
universal operating system directive.. I will never know! Debian
is a major force in global server software and therefore must
remain extremely stable, bug-free, and flexible.. all of which
systemd/gnome crapware nullifies!







--
Tony Thedford
Access Technologies
850 Belt Line Rd
Garland, TX 75040
Phone: 972.414.8356
Email: t...@accesslab.com

Bug#727708: call for votes on default Linux init system for jessie

[Jason Frothingham]

question for you:  which would you have Debian developers do:

A: complain about historical issues in systemd that have largely been
patched or addressed
B: complain about what systemd is like now
C: submit patches to systemd that fix outstanding bugs
D: submit patches to systemd that fix outstanding bugs and enable the
non-initialization portions of systemd to work with other initialization
systems like OpenRC

If you selected A or B, I think I can identify your problem.  You seem to
have a mind set more typical of Moronix or Microsoft in which the existence
of software packages *in the past* is all those software packages *will
ever be in the future*.

While that might be an accurate assumption to be made of proprietary
software that is largely published and then only patched when something
breaks, such models are generally not true to Open Source Software packages
like KDE, the Linux Kernel, or Libre Office.  Such software packages
typically learn from coding mistakes in the past and new versions actively
address various issues. E.G. a very popular point right now is how the
lessons and resources from the Nepomuk development are being leveraged in
the development of Nepomuk 2.0, aka Baloo. :: Another popular point in
recent weeks can be found in the Open-Source X.org Radeon drivers starting
to trade blows in OpenGL 3.x class rendering with the proprietary Catalyst
driver set. :: Need I continue?

Now, I won't argue that the Gnome-Shell software is crapware; and you won't
find me arguing against similar points on GTK in general. The Gnome-Shell
and GTK developers are formed of infamous cliques that have done more to
discourage modern developers than encourage them. Need I point out Valve's
observations on the differences between QT and GTK development and the
interaction with upstream developers... or in the case of GTK... the lack
of interaction with upstream and existing developers.

I will argue that writing off systemd so quickly is a huge mistake. Do keep
in mind that with less than half the development time (2010~2014) compared
to Canonical's Upstart (2006~2014), the systemd initialization system alone
managed to reach at least on-paper parity; if not in-practice parity; with
the older software package. A large part of that rapid pace of comparative
development was the loss of FOSS oriented developers who chafed at
Canonical's CLA licensing modification. No, I'm not letting that one go, it
is that big a deal: especially for Debian's stances on Software licensing.

Are such statements to be an understanding or equivalency as a statement
that systemd is a perfect software solution? *NO*.  Nobody here on Debian
even got close to suggesting such a thing. The closest anybody here on
these mailing lists got were statements that as of right now, *systemd is
better than SysVInit on Linux.*

Adopting systemd does not, in any way shape, form, idea, concept,
conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc.
etc. the goal of a computationally stable, bug-free, and flexible operating
system.

So do this, and other mailing lists a favor, knock off the Fear,
Uncertainty, and Doubt.  if you have the coding chops to actually comment
on systemd's capabilities and features; or lack-thereof; at a code level
rather than just at a Moronix Level, you'd probably be better off diving in
and fixing bugs yourself.


On Tue, Feb 18, 2014 at 9:06 PM, Tony Thedford  wrote:

> Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I
> would say! As to why there are developers within Debian who are hellbent on
> turning Debian into buggy desktop software rather than keeping with the
> universal operating system directive.. I will never know! Debian is a major
> force in global server software and therefore must remain extremely stable,
> bug-free, and flexible.. all of which systemd/gnome crapware nullifies!
>
>
>
> --
> Tony Thedford
> Access Technologies
> 850 Belt Line Rd
> Garland, TX 75040
> Phone: 972.414.8356
> Email: t...@accesslab.com
>
>
> --
> To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/530411b8.7060...@accesslab.com
>
>


-- 
Jason Frothingham.
http://www.linux-guides.com
http://http://forum.mepiscommunity.org/
http://www.mepis.org
http://www.gamenikkiinexile.com
http://gplus.to/JeSaist

Bug#727708: call for votes on default Linux init system for jessie

[Tony Thedford]

Putting the "systemd" issue on bugs.debian.org is a bit ridiculous I 
would say! As to why there are developers within Debian who are hellbent 
on turning Debian into buggy desktop software rather than keeping with 
the universal operating system directive.. I will never know! Debian is 
a major force in global server software and therefore must remain 
extremely stable, bug-free, and flexible.. all of which systemd/gnome 
crapware nullifies!




--
Tony Thedford
Access Technologies
850 Belt Line Rd
Garland, TX 75040
Phone: 972.414.8356
Email: t...@accesslab.com


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530411b8.7060...@accesslab.com

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
> On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
> > On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
> > > > "Bdale" == Bdale Garbee  writes:
> > 
> > > Bdale> Steve Langasek  writes:
> > > >> FWIW I have always assumed that the casting vote is implicit in
> > > >> the chair's ballot.  To require the chair to explicitly exercise
> > > >> their casting vote, as opposed to the chair's preferences as
> > > >> expressed on the ballot being applied automatically, opens up
> > > >> another set of vote gaming strategies that we really shouldn't
> > > >> get into.
> > 
> > > Bdale> I would have assumed that, too, but since others did not
> > > Bdale> share the assumption, it seemed prudent to be explicit about
> > > Bdale> it.
> > 
> > > This assumption does not make sense to me in the following cases:
> > 
> > > * Chair ranks multiple options equilly
> > 
> > If the chair ranked them equally in his ballot, why should he express a
> > different preference when it comes to the casting vote?
> 
> I think the vote should always result in something, and as such
> the person having the casting vote needs to pick one of the
> options that are left in the Schwartz set.  If there was no
> preference between them, a choise will still need to be made.
> 
> I've actually been wondering about this issue myself the past few
> days, and this seems to me the only good reason why the casting
> vote should be a different vote than the earlier vote.

Somewhere buried in this huge thread I had a discussion with Anthony 
regarding it, and in my opinion there is another possible good reason:

Assume in Ian's previous combined ballot where voting was aborted the 
two remaining members would have voted, and both had voted DT > DL > FD.

The result would have been:

DT > FD (5:3)
DL > FD (8:0)
DT = DL (4:4)

One can argue that the the chairman should simply pick whatever he 
personally prefers.

My point here is that the chairman should IMHO at least consider the 
fact that there is one option that is acceptable for all members, while 
the other option is vehemently opposed by 3 TC members.

And choosing a generally acceptable option over his personal preference 
would be a good reason for voting different in the casting vote.[1]

> Kurt

cu
Adrian

[1] The chairman has no obligation to change his vote in such a case,
but if he would there would be a good reason and not just random
erratic behaviour.

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140211210918.ga26...@bunk.dyndns.info

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Matthias Urlichs  writes:
> Steve Langasek:

>> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
>> preferences among all the ballot options, not just our first-choice
>> preference.  The chair using a casting vote between two tied options
>> (or three, which is the problematic case) is expressing a preference
>> for one over the other; if such a preference exists, the non-strategic
>> vote is to express this same preference in the original ballot.

> The chair might desire to use their casting vote to select the more
> popular | less controversial | more- (or less-)vocally-supported option,
> as opposed to their personal opinion | preference.

Can I suggest that this discussion may be better placed in debian-project?
The procedural issue is really a concern for the project as a whole, and
any changes would be constitutional changes and would have to go through
the project as a whole.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjlxpdje@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Matthias Urlichs]

Hi,

Steve Langasek:
> "Obvious", but wrong.  We use Condorcet to enable fully expressing our
> preferences among all the ballot options, not just our first-choice
> preference.  The chair using a casting vote between two tied options (or
> three, which is the problematic case) is expressing a preference for one
> over the other; if such a preference exists, the non-strategic vote is to
> express this same preference in the original ballot.
> 
The chair might desire to use their casting vote to select the more popular |
less controversial | more- (or less-)vocally-supported option, as opposed
to their personal opinion | preference.

> The *only* use of a casting vote that is different from the original ballot
> is a strategic one, and we should never allow this.

I disagree.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Tollef Fog Heen]

]] Steve Langasek 

> The *only* use of a casting vote that is different from the original ballot
> is a strategic one, and we should never allow this.  In the case described,
> the chair should just express the preference between the remaining options
> (perhaps by amending their vote, which is allowed so long as "the outcome
> is in doubt"), in which case the casting vote clause doesn't come into play
> at all.

The vote might have ran out of time, in which case I believe it's too
late to change any votes, but not to use the casting vote.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2a9dxtmr4@rahvafeir.err.no

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Tue, Feb 11, 2014 at 11:54:50AM -0800, Keith Packard wrote:
> Steve Langasek  writes:

> > If the chair ranked them equally in his ballot, why should he express a
> > different preference when it comes to the casting vote?

> Oh, the obvious answer -- if the chair's preference didn't end up in the
> tie, he'd have to explicitly vote from the remaining options.

"Obvious", but wrong.  We use Condorcet to enable fully expressing our
preferences among all the ballot options, not just our first-choice
preference.  The chair using a casting vote between two tied options (or
three, which is the problematic case) is expressing a preference for one
over the other; if such a preference exists, the non-strategic vote is to
express this same preference in the original ballot.

The *only* use of a casting vote that is different from the original ballot
is a strategic one, and we should never allow this.  In the case described,
the chair should just express the preference between the remaining options
(perhaps by amending their vote, which is allowed so long as "the outcome
is in doubt"), in which case the casting vote clause doesn't come into play
at all.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Antti-Juhani Kaijanaho]

On Tue, Feb 11, 2014 at 08:22:19PM +0100, Kurt Roeckx wrote:
> I think the vote should always result in something, and as such
> the person having the casting vote needs to pick one of the
> options that are left in the Schwartz set.  If there was no
> preference between them, a choise will still need to be made.

I have, when serving as a chair of an association meeting, voted blank in many
occasions, and in the one case where it resulted in a tie, I used my casting
vote to resolve it.  In those cases, it was not important for me to choose
between the options during the regular vote, hence the blank vote.  However,
when the vote resulted in a tie, I had an obligation, imposed by law, custom
and the association's constitution, to choose; and I did.

However, in any vote where I as a chair have already voted non-blank, I feel it
would be wrong for me to choose another option for my casting vote.

Of course, the rules of order for a Finnish association are rather different
from those used by Debian's TC, so there's no direct relevance to this case.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140211195726.gb3...@kukkavihko.kaijanaho.fi

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Steve Langasek  writes:

> If the chair ranked them equally in his ballot, why should he express a
> different preference when it comes to the casting vote?

Oh, the obvious answer -- if the chair's preference didn't end up in the
tie, he'd have to explicitly vote from the remaining options.

-- 
keith.pack...@intel.com


pgpQiPLG5GnC1.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Kurt Roeckx]

On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote:
> On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
> > > "Bdale" == Bdale Garbee  writes:
> 
> > Bdale> Steve Langasek  writes:
> > >> FWIW I have always assumed that the casting vote is implicit in
> > >> the chair's ballot.  To require the chair to explicitly exercise
> > >> their casting vote, as opposed to the chair's preferences as
> > >> expressed on the ballot being applied automatically, opens up
> > >> another set of vote gaming strategies that we really shouldn't
> > >> get into.
> 
> > Bdale> I would have assumed that, too, but since others did not
> > Bdale> share the assumption, it seemed prudent to be explicit about
> > Bdale> it.
> 
> > This assumption does not make sense to me in the following cases:
> 
> > * Chair ranks multiple options equilly
> 
> If the chair ranked them equally in his ballot, why should he express a
> different preference when it comes to the casting vote?

I think the vote should always result in something, and as such
the person having the casting vote needs to pick one of the
options that are left in the Schwartz set.  If there was no
preference between them, a choise will still need to be made.

I've actually been wondering about this issue myself the past few
days, and this seems to me the only good reason why the casting
vote should be a different vote than the earlier vote.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140211192219.ga9...@roeckx.be

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote:
> > "Bdale" == Bdale Garbee  writes:

> Bdale> Steve Langasek  writes:
> >> FWIW I have always assumed that the casting vote is implicit in
> >> the chair's ballot.  To require the chair to explicitly exercise
> >> their casting vote, as opposed to the chair's preferences as
> >> expressed on the ballot being applied automatically, opens up
> >> another set of vote gaming strategies that we really shouldn't
> >> get into.

> Bdale> I would have assumed that, too, but since others did not
> Bdale> share the assumption, it seemed prudent to be explicit about
> Bdale> it.

> This assumption does not make sense to me in the following cases:

> * Chair ranks multiple options equilly

If the chair ranked them equally in his ballot, why should he express a
different preference when it comes to the casting vote?  Or, put
differently: if the chair comes to a decision about which of the
equally-ranked options should win, why should that decision not be reflected
in his main vote (with the effect that the "casting" vote will not be used
at all)?

> * All of the options that the chair is choosing between were ranked by
>   the chair below FD

Being below FD does not imply that no preference is being expressed between
the options.  Rankings between such options are taken into account at every
other stage of the vote, there's no reason it should be different for the
casting vote.

> * At least one of the options was not ranked by the chair.

Unranked options are treated as ranked last, so whichever option is *not*
unranked gets the vote.

> * I don't know if casting votes can come up in DPL elections or if there
> are any other circumstances with secret ballots.

If they are, why should the casting vote be less secret than the normal
ballot?

> I think you're safer just casting an explicit casting vote.

The only case in which it makes a difference to have an explicit casting
vote is when the preferences expressed in the casting vote do not match the
preferences expressed in the standard vote.  If that ever happened, it would
be an act of strategic voting.  When all other aspects of our voting system
are designed to minimize the rewards of strategic voting, this seems an
unnecessary bug.  It's a low-impact bug, because it requires both three
nearly-balanced ballot options, and a TC chair willing to engage in
strategic voting for all the world to see; but it's still a bug.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Sam Hartman]

> "Bdale" == Bdale Garbee  writes:

Bdale> Steve Langasek  writes:
>> FWIW I have always assumed that the casting vote is implicit in
>> the chair's ballot.  To require the chair to explicitly exercise
>> their casting vote, as opposed to the chair's preferences as
>> expressed on the ballot being applied automatically, opens up
>> another set of vote gaming strategies that we really shouldn't
>> get into.

Bdale> I would have assumed that, too, but since others did not
Bdale> share the assumption, it seemed prudent to be explicit about
Bdale> it.

This assumption does not make sense to me in the following cases:

* Chair ranks multiple options equilly

* All of the options that the chair is choosing between were ranked by
  the chair below FD

* At least one of the options was not ranked by the chair.

* I don't know if casting votes can come up in DPL elections or if there
are any other circumstances with secret ballots.

I think you're safer just casting an explicit casting vote.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslppmtwost@mit.edu

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Tue, Feb 11, 2014 at 07:35:13AM -0700, Bdale Garbee wrote:
> Anthony Towns  writes:

> > A.6.6: Schwartz set is {D,U}
> > A.6.8: There are no defeats in the Schwartz set, so the elector with
> >the casting vote chooses which of these options wins.

> > Per 6.3.2, the casting vote is held by the Chairman, who is currently
> > Bdale.

> Thank you, Anthony, for your analysis of the votes.

> Per 6.3.2, I use my casting vote to choose D as the winner.

FWIW I have always assumed that the casting vote is implicit in the chair's
ballot.  To require the chair to explicitly exercise their casting vote, as
opposed to the chair's preferences as expressed on the ballot being applied
automatically, opens up another set of vote gaming strategies that we really
shouldn't get into.

(Obviously there's no gaming here, as Bdale's casting vote is consistent
with his ballot; but let's not set a bad precedent...)

Thanks,
-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Steve Langasek  writes:

> FWIW I have always assumed that the casting vote is implicit in the chair's
> ballot.  To require the chair to explicitly exercise their casting vote, as
> opposed to the chair's preferences as expressed on the ballot being applied
> automatically, opens up another set of vote gaming strategies that we really
> shouldn't get into.

I would have assumed that, too, but since others did not share the
assumption, it seemed prudent to be explicit about it.  

I suppose it's always possible that the chair might change their mind
after seeing how votes are cast and the comments associated with those
votes.  Should the project choose to try and amend the constitution at
some point to address corner cases in the voting process or TC rules of
engagement exposed through this process, this might be a detail worth
addressing explicitly.

On the other hand, we have never needed the TC casting vote before, and
I sincerely hope we never do again.  

Bdale


pgpoGSbWdPlnE.pgp
Description: PGP signature

Bug#727708: [Fwd: Re: Bug#727708: call for votes on default Linux init system for jessie]

[Emilio Pozuelo Monfort]

On 11/02/14 16:09, Svante Signell wrote:
> How can you make this statement when the voting period is not over?
> What if some CTTE members decide to change their vote?

Debian Constitution 6.3.1:

"the voting period lasts for up to one week, or until the outcome is no longer
in doubt."

Given that all eight committee members have voted and the outcome is no longer
in doubt, the voting period is over and the chairman of the committee can use
his casting vote.

> Andreas Barth changed his vote today!

No, he hasn't changed his vote. He has voted today but he hasn't changed his
vote as he hadn't voted before on this resolution. That is why the outcome was
still "in doubt", as Andreas could have ranked D above U, making the outcome
different (just D in the Schwartz set and no need for the casting vote).

Emilio


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fa43dd.6040...@debian.org

Bug#727708: [Fwd: Re: Bug#727708: call for votes on default Linux init system for jessie]

[Svante Signell]

--- Begin Message ---

> Anthony Towns  writes:
> 
> > A.6.6: Schwartz set is {D,U}
> > A.6.8: There are no defeats in the Schwartz set, so the elector with
> >the casting vote chooses which of these options wins.
> >
> > Per 6.3.2, the casting vote is held by the Chairman, who is currently
> > Bdale.
> 
> Thank you, Anthony, for your analysis of the votes.
> 
> Per 6.3.2, I use my casting vote to choose D as the winner.
> 
> Therefore, the resolution reads:
> 
>   We exercise our power to decide in cases of overlapping jurisdiction
>   (6.1.2) by asserting that the default init system for Linux
>   architectures in jessie should be systemd.
> 
>   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.
> 
> Bdale

How can you make this statement when the voting period is not over?
What if some CTTE members decide to change their vote? Andreas Barth
changed his vote today!

--- End Message ---

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Anthony Towns  writes:

> A.6.6: Schwartz set is {D,U}
> A.6.8: There are no defeats in the Schwartz set, so the elector with
>the casting vote chooses which of these options wins.
>
> Per 6.3.2, the casting vote is held by the Chairman, who is currently
> Bdale.

Thank you, Anthony, for your analysis of the votes.

Per 6.3.2, I use my casting vote to choose D as the winner.

Therefore, the resolution reads:

  We exercise our power to decide in cases of overlapping jurisdiction
  (6.1.2) by asserting that the default init system for Linux
  architectures in jessie should be systemd.

  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.

Bdale


pgpOCVf29EzHJ.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
> Bdale Garbee  writes:
> > - - - start ballot - - -
> > We exercise our power to decide in cases of overlapping jurisdiction
> > (6.1.2) by asserting that the default init system for Linux
> > architectures in jessie should be
> >   Dsystemd 
> >   Uupstart
> >   Oopenrc
> >   Vsysvinit (no change)
> >   Frequires further discussion
> > 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.
> > - - - end ballot - - -
> I vote D U O V F.

On Sat, Feb 08, 2014 at 12:16:51PM -0800, Russ Allbery wrote:
> I vote:
> D U O V F

On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
> I vote F U D O V

On Sat, Feb 08, 2014 at 02:51:13PM -0800, Don Armstrong wrote:
> I vote D > U > O > V > F.

On Sat, Feb 08, 2014 at 02:57:52PM -0800, Keith Packard wrote:
> I vote:
> 1.  D
> 2.  U
> 3.  O
> 4.  V
> 5.  F

On Sun, Feb 09, 2014 at 01:04:31PM +, Colin Watson wrote:
> I vote UDOFV.

On Sun, Feb 09, 2014 at 07:15:58PM +, Ian Jackson wrote:
> I vote F, V, O, U, D.

On Tue, Feb 11, 2014 at 09:07:11AM +0100, Andreas Barth wrote:
> Thus voting U, F, D, O, V.

So that's all the votes in, by my count. Summary is:

  4x D U O V F (bdale, russ, keith, don)
 F U D O V (steve)
 U D O F V (colin)
 F V O U D (ian)
 U F D O V (andi)

Pairwise defeats are:

  D = U  (4:4)

  U and D > O and V  
 (7:1) (ian against)
  O > V  (7:1) (ian against)

  U > F  (6:2) (steve, ian against)
  D > F  (5:3) (steve, ian, andi against)
  O > F  (5:3) (steve, ian, andi against)
  V = F  (4:4)

A.6.2: Quorum is 2 (6.3.1), all options meet quorum.
A.6.3: Option V does not strictly defeat default option F, so is eliminated
A.6.5: Transitive defeats are:

  D : O, F (directly)
  U : O, F (directly)
  O : F (directly)
  F :

A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
   the casting vote chooses which of these options wins.

Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.

Per 6.3.1, the voting period expires either Feb 15th, or when the outcome
is no longer in doubt. Not clear to me if that's now, or only after Bdale
specifies a casting vote. Per 7.3, if there's any dispute about that, the
secretary adjudicates that dispute.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140211084517.ga21...@master.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Andreas Barth]

* Bdale Garbee (bd...@gag.com) [140208 20:50]:
> I expect that Debian can and should continue to support multiple init
> systems for the foreseeable future.  I also believe that Debian can and
> should take an active role working with upstream projects on software
> that is important to us, such as init system projects. 

[...]

> - - - start ballot - - -
> 
> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be
> 
>   Dsystemd 
> 
>   Uupstart
> 
>   Oopenrc
> 
>   Vsysvinit (no change)
> 
>   Frequires further discussion
> 
> 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.
> 
> - - - end ballot - - -

I'm unhappy with this resolution; in fact, after the discussions I
don't think it would be good to decide on an init system without
explicitly stating that users should be able to continue to make
different decisions on their own systems (and in hindsight it was an
error that I voted FD on the previous call for votes to allow textual
optimizations). This is especially true for systemd (I consider the
probability of people to depend soley on upstart to be lower) - after
some long thinking about this I came to the conclusion that I cannot
vote systemd above further discussion in the current scenario. (Also I
hope but don't expect that the discussions we had on our list are
enough for maintainers to not try to force a specific init system on
our users.)


Thus voting U, F, D, O, V.


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140211080711.gz16...@mails.so.argh.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 10 February 2014 06:41, Serge Kosyrev  wrote:
> False.  Three messages on this list brought this conflict of interest
> into light:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
> [...]
> There was no answer.

So, fwiw, I thought the above was kind of mean on my behalf. Not
/wrong/ per se, just mean.

I haven't been able to think of a *good* "answer" for this concern,
even in an arbitrary ideal world where the constraints are different.

For instance, Steve could recuse himself from the discussion entirely
-- that's what you'd expect in many cases where there are commercial
conflicts of interest, eg. But that would be ridiculous here, because
both his technical knowledge as upstart maintainer is nigh-on
essential to the discussion, and his input as to how things have
worked in Canonical is pretty useful too.

He could recuse himself from voting, or perhaps the committee chair or
committee as a whole could ask him to do so -- but at least at this
point, that would be effectively equivalent to Steve directly voting
systemd above upstart, and that would be a fairly unreasonable forced
reversal of preferences for Steve to make, or it would involve a
conflict of interest on behalf of the chair (who's indicated a
preference for systemd), or the rest of the committee (which has
indicated a 4:3 preference for systemd). Maybe one of these things
would have been good to do earlier, before positions had coalesced,
but I don't think they're reasonable things to do or expect now. (They
might have been when I sent the mail, but if so, they only remained
plausible for a pretty short window in my opinion; further, Steve
mentions that the committee discussed this earlier and came to the
conclusion that no action was needed)

If the committee had the flexibility to do so, maybe a reasonable
thing would have been to replace Steve for this vote with a less
interested party early in the discussions; eg by letting Phil Kern
step in to provide the 8th vote for this issue, so that Steve could
simply act as an advocate and technical advisor to the committee on
this issue. Alternatively, perhaps a reasonable thing might have been
to give the primary systemd, sysvinit and upstart maintainers the
ability to vote on this issue too. Neither were options open to the
committee though.

As it stands, though, Steve has to: consider the implications for
Debian, consider the implications for upstart (as maintainer),
consider the implications for Canonical and Ubuntu (as a Canonical
employee and Ubuntu dev), mostly dismiss the implications for
Canonical/Ubuntu (in order to prioritise the implications for Debian
as a ctte member making a ctte decision), and deal with accusations of
having a conflict of interest, despite not being able to do anything
concrete to address them. Oh, and I gather Steve's trying to run a
debconf in six months time or so too, which I understand could add
some degree of stress on its own...

So yeah, I stand by my description of that as "fairly challenging",
and I'm really glad it's not me in that position.

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajs_lcxoeoohwrkhlk67rjhcobonfqg-b6zat9sow5vd2aq...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Mon, Feb 10, 2014 at 12:41:38AM +0400, Serge Kosyrev wrote:
> Serge Kosyrev  writes:
> > On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
> > > > I vote UDOFV.

> > > So, this vote effectively gives systemd the win (assuming Bdale opts
> > > for the casting vote).

> > > This trumps the fact that Steve was in the midst of drafting a
> > > potentially agreeable ballot all around, and had stated his
> > > disappointment about this out of the blue CFV since he just needed
> > > some more time to get that done.

> > Many have voiced the concern I'm going to address, but as I see your
> > words, I cannot help but see the need to reiterate.

> > There is a point of view, that Steve's role as a debian's upstart maintainer
> > is in a direct conflict with the spirit of the process here.

> > From such a viewpoint, one would rather see Steve abstain from
> > _any_ participation on bug #727708.

> > In fact, one can't help but be amazed at the level of tolerance to this
> > issue from other members of the CTTE.

> Ondřej Surý  writes:
> > This has been repeated many times

> I have said so, indeed -- as well as stated a reason for reiteration.

Whether my conflict of interest in this decision constitutes a problem is a
question for the Debian project to decide, not you.  I have been convinced,
as a result of conversations with my fellow TC members early in this
process, that there was no need for me to recuse myself from the discussion. 
If the Debian Developers feel that my conflict of interest has resulted in a
wrong decision being taken, they have the authority to override the TC with
a GR.

But until then, kindly stop distracting the committee from its rightful
business.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Serge Kosyrev]

Serge Kosyrev  writes:
> On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
> > > I vote UDOFV.
> >
> > So, this vote effectively gives systemd the win (assuming Bdale opts
> > for the casting vote).
> >
> > This trumps the fact that Steve was in the midst of drafting a
> > potentially agreeable ballot all around, and had stated his
> > disappointment about this out of the blue CFV since he just needed
> > some more time to get that done.
> 
> Many have voiced the concern I'm going to address, but as I see your
> words, I cannot help but see the need to reiterate.
> 
> There is a point of view, that Steve's role as a debian's upstart maintainer
> is in a direct conflict with the spirit of the process here.
> 
> From such a viewpoint, one would rather see Steve abstain from
> _any_ participation on bug #727708.
>
> In fact, one can't help but be amazed at the level of tolerance to this
> issue from other members of the CTTE.

Ondřej Surý  writes:
> This has been repeated many times

I have said so, indeed -- as well as stated a reason for reiteration.

> and refused

False.  Three messages on this list brought this conflict of interest
into light:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5912 by Friedrich 
Gunther
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6206 by Dmitry Smirnov

There was no answer.

> and I would really prefer that you would stop
> reiterating this again and again. It's really annoyning and it feels like you 
> are not listening
> anf just blindly repeating your position. Please stop, you are not helping 
> neither Debian nor
> the process.

Such is your unexplained (and ill-substantiated) preference.

-- 
regards,
Samium Gromoff


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878utk588t@andromedae.feelingofgreen.ru

Bug#727708: call for votes on default Linux init system for jessie

[Serge Kosyrev]

On Sun, Feb 9, 2014 at 19:27, Michael Gilbert wrote:
> > I vote UDOFV.
>
> So, this vote effectively gives systemd the win (assuming Bdale opts
> for the casting vote).
>
> This trumps the fact that Steve was in the midst of drafting a
> potentially agreeable ballot all around, and had stated his
> disappointment about this out of the blue CFV since he just needed
> some more time to get that done.

Many have voiced the concern I'm going to address, but as I see your
words, I cannot help but see the need to reiterate.

There is a point of view, that Steve's role as a debian's upstart maintainer
is in a direct conflict with the spirit of the process here.

>From such a viewpoint, one would rather see Steve abstain from
_any_ participation on bug #727708.

In fact, one can't help but be amazed at the level of tolerance to this
issue from other members of the CTTE.

-- 
regards,
Samium Gromoff


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwi05hto@andromedae.feelingofgreen.ru

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sun, Feb 9, 2014 at 8:04 AM, Colin Watson wrote:
> I vote UDOFV.

So, this vote effectively gives systemd the win (assuming Bdale opts
for the casting vote).

This trumps the fact that Steve was in the midst of drafting a
potentially agreeable ballot all around, and had stated his
disappointment about this out of the blue CFV since he just needed
some more time to get that done.

Wouldn't it be far more preferable to take a little more time to
refine the text so that it can be backed by a somewhat unified TC?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOXEJGymKCV1Ovh91gH9mP5Z-yNayhmaG6AEbke__Z=9...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Matthias Urlichs]

Hi,

Michael Gilbert:
> I'd be happy to see a change post-jessie, but I feel like it is a
> self-imposed rush to push anything through for jessie.
> 
Given that certain other distributions switched to systemd umpteen months
ago, I see that less as "rushing" and more as "we're late to the game and
do NOT want to burden everybody with buggy init scripts, missing features,
and an unmaintained pseudo-solution (ConsoleKit) for another two+ years".

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140209141807.gc14...@smurf.noris.de

Bug#727708: call for votes on default Linux init system for jessie

[Colin Watson]

On Sat, Feb 08, 2014 at 12:49:37PM -0700, Bdale Garbee wrote:
> I have carefully considered Ian's current proposal for a process and
> schedule to reach a next ballot on the init system issue, and do not
> believe it is the best way for us to proceed.
> 
> The fundamental problem is that I remain as convinced now as I was when
> I posted my last CFV that conflating multiple questions in a single
> ballot is a bad idea.  Our voting system works exceptionally well when
> we're trying to choose between multiple alternatives for a single
> question.  But as others have observed, trying to mix questions into a
> matrix of alternatives in a single ballot really complicates the
> process.  I believe it both tempts us all to take a more tactical
> approach to voting than appropriate, and increases the risk of stumbling
> over corner cases in the process which could lead to surprising results.

I have a lot of sympathy with Ian's position here, hence my previous FD
votes; I think we do need to finish hashing this out, and it was
valuable to run the combined votes (even abortively) since the
combination certainly could have made a significant and important
difference.  However, looking through the votes cast so far, I do not
see how separating them is actually going to make a discernible
difference to the outcome of either part, and so I don't feel that I can
personally justify holding things up any more for this.  I also hope
that resolving this part will vent a little pressure so that we can deal
with the rest more effectively.

> As per Constitution 6.3.1, I call for an immediate vote on the following
> ballot, with a voting period of one week or until the outcome is no
> longer in doubt:
> 
> - - - start ballot - - -
> 
> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be
> 
>   Dsystemd 
> 
>   Uupstart
> 
>   Oopenrc
> 
>   Vsysvinit (no change)
> 
>   Frequires further discussion
> 
> 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.

I vote UDOFV.

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


signature.asc
Description: Digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Richard Hartmann]

On Sat, Feb 8, 2014 at 11:51 PM, Don Armstrong  wrote:
> I vote D > U > O > V > F.

I would appreciate it if you could reply to self with signed mail
re-stating this.


Thanks,
Richard


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cad77+gr_xskdedygzfvdpn-emmkowre16+7edddcfqdpmph...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 9 February 2014 09:52, Russ Allbery  wrote:
> If you're looking for Policy Editors who enjoy running things through a
> process that won't be successful just so that we can say they've been run
> through a process, you're going to need someone other than me.

In that case, wouldn't it make sense to have a quick chat with the
other policy editors about officially delegating the task of deciding
on policy for depending on init systems to the tech ctte?

Could even open a new bug for it!

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajs_lcvyxkwb8sg1v+pgsj+kle1+2qyxyogzgvl_h1sf4-2...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 9:23 PM, Michael Gilbert wrote:
> Instead, none of the important implementation related stuff has been 
> discussed.

Correction, a lot of that has been discussed, but there has been no
progress on it due to the distraction on the bigger political problem.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOB1NbQvMm3b2yytnfZYaa8r9OPFKN=mdb_vpa1i-z...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 9:08 PM, Paul Tagliamonte wrote:
> On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote:
>> Paul, you know I think you're awesome, but you've stirred up a whole
>> lot of trouble here with a questionable motive.
>
> What motive is that, if I might ask?[1] :)
> [1]: Assuming ill intent are we?

Not my intent to give that impression at all.  I know you have the
best of intentions, but the phrasing of the question posed lead the TC
in a very specific high controversy direction.

I think it would have been better to ask for some smaller less
controversial decisions solving existing known init system related
problems (like logind), and once enough of those were decided, it
would probably be abundantly clear which default the init should
change to.

Instead, none of the important implementation related stuff has been discussed.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mon+h-wtcalcws7fnvj3+swwsxcfs3fdmzr_-1rvss...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Paul Tagliamonte]

On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote:
> Why bring such a controversial and polarizing issue before the TC if
> the outcome doesn't matter much to you?

OK, phrased badly. I don't care what it is, so long as it's not
sysvinit :)

I believe it to be broken, and not a future-proof solution, and I
assumed that was sorta taken for granted that others agreed. The general
consensus[0] is that sysvinit is not a solution going forward.

> sysvinit is maintainable and stable, so why seek to change it?

It's stable, but it's not going to be maintainable in the long-run, and
I believe it will become unmaintainable very soon.

> Paul, you know I think you're awesome, but you've stirred up a whole
> lot of trouble here with a questionable motive.

What motive is that, if I might ask?[1] :)

We were already flaming pretty hard, it was out of control, it was in
the best interest of everyone to get it resolved in a quick way. I
believed (and still believe) the TC was the best way out of the
situation, so I did the natrual thing.

I care in so far as we are able to keep Debian maintainable and use
software that allows future releases[2] to get sent to users without
fuss.

> Best wishes,
> Mike

Much love,
  Paul

[0]: Yes, I know tg disagrees.
[1]: Assuming ill intent are we?
[2]: of Debian itself and new upstream releases (say, GNOME)

-- 
 .''`.  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

Bug#727708: call for votes on default Linux init system for jessie

[Tollef Fog Heen]

]] Steve Langasek 

> Annoyed, yes.  Blocked, no.  There has never been anything blocking any
> Debian developer from doing work on improving the integration of systemd in
> Debian, on their own packages or on the packages of others.  This has always
> been possible, without making systemd the default at all.

It seems a bit pointless to start doing the work on how to change the
default to systemd until that was actually decided.  Once we have a
decision (and assuming that the default will be systemd), I was planning
on starting at looking at how to best do the transition.

So maybe not blocked as such, but «annoyed and unwilling to spend effort
that might be wasted».

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m238jt3yoc@rahvafeir.err.no

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 7:17 PM, Russ Allbery wrote:
> Look, I've been involved in Policy work for years now.  I think I have a
> pretty good intuition for what sort of questions can be dealt with
> usefully in that framework and which ones can't.  You're certainly
> entitled to think that I'm wrong, but it's unlikely that I'm going to
> change my mind on this particular question, since I don't think it's even
> close.
>
> It's hard to avoid the feeling that you'd rather not have the TC discuss
> this question since the TC is arriving at a conclusion that you don't
> like.

It's not that I dislike any particular conclusion, it is that I
dislike the apparent rush toward conclusion.  The TC is a deliberative
body that is only supposed to act when all normal means have been
exhausted.  The fact that no policy discussion ever happened means
that something has really going wrong here.

I'd be happy to see a change post-jessie, but I feel like it is a
self-imposed rush to push anything through for jessie.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPKyYmYGzxo6kFzkAZrA_-0=-7jnwpri9wuabvmbes...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Sat, Feb 08, 2014 at 03:53:40PM -0800, Russ Allbery wrote:
> Steven Chamberlain  writes:

> > IMHO it was a little frustrating that Ian's ballot couldn't go ahead
> > last week and reach a consensus on both issues.

> I would be very interested in your comments, from the perspective of a
> non-Linux port maintainer, on the language that Steve and I have been
> discussing.

FWIW, it occurred to me about a week ago that, although we've been
discussing a question that has implications for all of Debian ports (even if
the current ballot only considers the Linux ports), at no time has the TC
actually asked the Hurd and FreeBSD porters for input - aside from those who
have found their own way to this bug.  Considering that some of the
discussions have made assumptions about what the porters will be inclined to
implement given a particular decision by the TC, I think this is an
oversight that we should correct by explicitly reaching out to the porter
lists.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Michael Gilbert  writes:
> On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote:

>> If you're looking for Policy Editors who enjoy running things through a
>> process that won't be successful just so that we can say they've been
>> run through a process, you're going to need someone other than me.  I
>> find that sort of thing to be tedious in the extreme and a giant waste
>> of everyone's time.  I have about four thousand things I could be
>> working on in Debian that would be more useful than going through that
>> exercise.

> That's only true if someone does actually get in the way.  There may
> actually be a clear path to consensus at this point, given that you
> already seem to have people from both D and U sides apparently agreeing
> in private.

There aren't any private discussions about the T and L options between TC
members that aware of, for whatever it's worth.  All the discussion is
here on the bug.  We got to a place where we're hammering out something
we're all happy with only in the context of a decision-making process and
two failed votes, and only by discussing options that one of the parties
to the discussion has explicitly rejected as unacceptable.

Look, I've been involved in Policy work for years now.  I think I have a
pretty good intuition for what sort of questions can be dealt with
usefully in that framework and which ones can't.  You're certainly
entitled to think that I'm wrong, but it's unlikely that I'm going to
change my mind on this particular question, since I don't think it's even
close.

It's hard to avoid the feeling that you'd rather not have the TC discuss
this question since the TC is arriving at a conclusion that you don't
like.  That's understandable, but I don't think the results are going to
be any more to your liking regardless of the forum, whether it be the TC,
a GR, or Policy.  I certainly don't believe, after having waded through
most of the debian-devel threads on the topic, that the project was going
to suddenly realize that everyone had good points and arrive at an
amicable consensus.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ha89jg0o@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote:
>> But at least it would follow the usual process, and only when
>> consensus does actually fail does the TC need to mediate.
>
> If you're looking for Policy Editors who enjoy running things through a
> process that won't be successful just so that we can say they've been run
> through a process, you're going to need someone other than me.  I find
> that sort of thing to be tedious in the extreme and a giant waste of
> everyone's time.  I have about four thousand things I could be working on
> in Debian that would be more useful than going through that exercise.

That's only true if someone does actually get in the way.  There may
actually be a clear path to consensus at this point, given that you
already seem to have people from both D and U sides apparently
agreeing in private.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MN+Er4TchQ506HeEoK65pH0P-==7Fj=fk8m3fuw+dl...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Cameron Norman]

El Sat, 8 de Feb 2014 a las 3:56 PM, Michael Gilbert 
 escribió:

On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:

 I understand you think that, and I empathize, but I disagree.

 The fact is, I have limited time. If I'm going to focus on making a
 bigger impact with my work, I'm going to stick to dealing with 
issues

 that effect the most users.

 I don't care about the init system all that much, in the end, it's 
not
 important. I do care about ensuring we have something maintainable 
and

 stable.


Why bring such a controversial and polarizing issue before the TC if
the outcome doesn't matter much to you?

sysvinit is maintainable and stable, so why seek to change it?



Perhaps the movement in GNOME to depend on a number of systemd provided 
interfaces has led Paul to believe that sysvinit is unmaintainable? 
AFAIR, systemd-shim was not available when he presented the question to 
the TC (or am I mistaken?).


--
Cameron

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:
> I understand you think that, and I empathize, but I disagree.
>
> The fact is, I have limited time. If I'm going to focus on making a
> bigger impact with my work, I'm going to stick to dealing with issues
> that effect the most users.
>
> I don't care about the init system all that much, in the end, it's not
> important. I do care about ensuring we have something maintainable and
> stable.

Why bring such a controversial and polarizing issue before the TC if
the outcome doesn't matter much to you?

sysvinit is maintainable and stable, so why seek to change it?

Paul, you know I think you're awesome, but you've stirred up a whole
lot of trouble here with a questionable motive.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOLEPvgD_wFJN8ow3Ok_0JzvLaE=c7pskzpq+o8x5o...@mail.gmail.com

Re: Bug#727708: call for votes on default Linux init system for jessie

[Cameron Norman]

El Sat, 8 de Feb 2014 a las 3:48 PM, Russ Allbery  
escribió:

Paul Tagliamonte  writes:

 As soon as we settle which init system is default (and by a rough 
count,

 I believe this issue is resolved now, thank you TC :) )

It's not.  All ballot options have to have a majority above FD in 
order to

be eligible to win the ballot.  At least one more person has to vote
another option above FD for there to be a winner other than FD.

If all remaining TC members vote FD first, FD wins.  That would be 
the way

of indicating support for Ian's position that we should not hold
independent votes.



I think it moreso indicates that if there are separate votes, that the 
init system choice can not be first. I do wonder, how many TC members 
would support voting on GR, then on T/L (or whatever it is you, Colin, 
and Steve are working on), then on the init system?


--
Cameron Norman

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Michael Gilbert  writes:
> On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:

>> Because -policy doesn't have a decision-making process other than
>> consensus, so Ian's objections to all of the positions shy of L and my
>> objections to L would deadlock and effectively block the -policy
>> discussion from ever reaching a decision.  There is no method for
>> either of us to be overridden.

> But at least it would follow the usual process, and only when
> consensus does actually fail does the TC need to mediate.

If you're looking for Policy Editors who enjoy running things through a
process that won't be successful just so that we can say they've been run
through a process, you're going to need someone other than me.  I find
that sort of thing to be tedious in the extreme and a giant waste of
everyone's time.  I have about four thousand things I could be working on
in Debian that would be more useful than going through that exercise.

> There would also presumably be proposed diffs to the policy text from
> both sides for the TC to review, and decide among the options, and
> that would be far more nuanced than this or that init as currently
> proposed.

I certainly hope that no one would spend lots of time drafting wording
without some broad agreement on what we wanted to say.  It's rare that the
question really rests on some point of minor nuance or phrasing; it's
better to hash out rough, broad statements until we get to some general
point of agreement and then work on diffs.  Otherwise, again, you run the
risk of wasting a bunch of people's time.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txc9jh76@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Steven Chamberlain  writes:

> IMHO it was a little frustrating that Ian's ballot couldn't go ahead
> last week and reach a consensus on both issues.

I would be very interested in your comments, from the perspective of a
non-Linux port maintainer, on the language that Steve and I have been
discussing.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppmxjh4r@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Steven Chamberlain]

On 08/02/14 23:24, Steve Langasek wrote:
> There has never been anything blocking any
> Debian developer from doing work on improving the integration of systemd in
> Debian, on their own packages or on the packages of others.

OTOH I'm eagerly awaiting the TC's decision[s] because it will likely
influence the direction of the non-Linux ports.

If Upstart had won somehow, most people working on GNU/kFreeBSD seemed
willing to adopt it on those grounds.  But it no longer seems the likely
choice for GNU/Linux.

And assuming systemd wins, a policy decision on dependencies and level
of coupling may lead to ports either supporting or dropping certain
packages, or a whole desktop environment.

IMHO it was a little frustrating that Ian's ballot couldn't go ahead
last week and reach a consensus on both issues.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



signature.asc
Description: OpenPGP digital signature

Re: Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Paul Tagliamonte  writes:

> As soon as we settle which init system is default (and by a rough count,
> I believe this issue is resolved now, thank you TC :) )

It's not.  All ballot options have to have a majority above FD in order to
be eligible to win the ballot.  At least one more person has to vote
another option above FD for there to be a winner other than FD.

If all remaining TC members vote FD first, FD wins.  That would be the way
of indicating support for Ian's position that we should not hold
independent votes.

If all remaining TC members other than one vote FD first and the remaining
one votes something else first, that option wins, since our resolution
method fails later-no-harm spectacularly.  As Steve points out, all those
who have voted so far have voted in explicit disregard to this
possibility.  I did so on the grounds that I refuse to vote tactically at
that level, and it sounds like Steve is of a similar feeling.

FWIW, that's also why I want to vote the issues separately, since it
avoids a giant tactical morass.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjm1jhdh@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> Why not hammer that out on -policy in public, and only if something goes
>> wrong there, then defer it to the TC?
>
> Because -policy doesn't have a decision-making process other than
> consensus, so Ian's objections to all of the positions shy of L and my
> objections to L would deadlock and effectively block the -policy
> discussion from ever reaching a decision.  There is no method for either
> of us to be overridden.

But at least it would follow the usual process, and only when
consensus does actually fail does the TC need to mediate.

There would also presumably be proposed diffs to the policy text from
both sides for the TC to review, and decide among the options, and
that would be far more nuanced than this or that init as currently
proposed.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOWM28M9k9Gx3oB-zMUpoMfYe7k=wbcvs9ubp1aw3r...@mail.gmail.com

Re: Bug#727708: call for votes on default Linux init system for jessie

[Paul Tagliamonte]

On Sat, Feb 08, 2014 at 03:24:34PM -0800, Steve Langasek wrote:
> > At this point, it's blocking folks inside Debian, who are stakeholders.
> > It's not just the trolls of reddit and the internet, it's DDs who are
> > annoyed there's no decision and integration work isn't started. We're
> > less than a year from freeze.
> 
> Annoyed, yes.  Blocked, no.  There has never been anything blocking any
> Debian developer from doing work on improving the integration of systemd in
> Debian, on their own packages or on the packages of others.  This has always
> been possible, without making systemd the default at all.

I understand you think that, and I empathize, but I disagree.

The fact is, I have limited time. If I'm going to focus on making a
bigger impact with my work, I'm going to stick to dealing with issues
that effect the most users.

I don't care about the init system all that much, in the end, it's not
important. I do care about ensuring we have something maintainable and
stable.

As soon as we settle which init system is default (and by a rough count,
I believe this issue is resolved now, thank you TC :) ), I can start
spending time on ensuring we have a polished distro throughout this
change by testing, and contributing patches when I hit issues that I
have time to fix.

I think this is the norm. I assure you it was not only annoying, but
also blocking.

> If anyone *does* think they are blocked in doing this integration work
> because the default has not been decided, that can only be because of a
> misunderstanding of what deciding the default *means*.

I don't grok. Default means it's going to be used by all users unless
they're technical enough to change it, in which case, I care slighly
less, since they're able to fix it and provide patches when they hit
issues.

> And that is
> precisely why I don't think it's good for the TC to send such an easily
> misinterpreted message by deciding the default without addressing the
> surrounding issues.

I understand why you might think that, but I believe it to not be
entirely in-line with how many view the situation.

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

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Sat, Feb 08, 2014 at 05:46:07PM -0500, Paul Tagliamonte wrote:
> > This should not be our priority.  Our purpose
> > here is to make sound technical decisions on behalf of the project, not to
> > preserve the TC's (or Debian's) "reputation" among third parties who have no
> > legitimate say in the outcome.

> At this point, it's blocking folks inside Debian, who are stakeholders.
> It's not just the trolls of reddit and the internet, it's DDs who are
> annoyed there's no decision and integration work isn't started. We're
> less than a year from freeze.

Annoyed, yes.  Blocked, no.  There has never been anything blocking any
Debian developer from doing work on improving the integration of systemd in
Debian, on their own packages or on the packages of others.  This has always
been possible, without making systemd the default at all.

If anyone *does* think they are blocked in doing this integration work
because the default has not been decided, that can only be because of a
misunderstanding of what deciding the default *means*.  And that is
precisely why I don't think it's good for the TC to send such an easily
misinterpreted message by deciding the default without addressing the
surrounding issues.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Michael Gilbert  writes:
> On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:

>> Well, in defense of the discussion that Steve, Colin, and I have been
>> having, I do think it's worthwhile for the TC to try to hammer out a
>> compromise on that point as well and express it as either technical
>> advice to the project or as technical policy.

> Why not hammer that out on -policy in public, and only if something goes
> wrong there, then defer it to the TC?

Because -policy doesn't have a decision-making process other than
consensus, so Ian's objections to all of the positions shy of L and my
objections to L would deadlock and effectively block the -policy
discussion from ever reaching a decision.  There is no method for either
of us to be overridden.

Now, there would have been no way of knowing in advance that something
like that would happen... but based on my past experience with Policy
discussions and the level of controversy over this particular question, I
would have been stunned if it hadn't happened, which is exactly why I
would have immediately punted to the TC.

Policy doesn't have a strong decision-making method other than consensus,
which means that it will fail to arrive at a conclusion for anything
that's even vaguely controversial (and sometimes even for things that are
not very controversial but which don't inspire people to express an
opinion).  Maybe that's a bug that should be fixed, or maybe we should
just use the TC as the way of reaching conclusions on controversial
issues; I can see arguments either way.  (The first Policy issue that I
escalated to the TC as an experiment in using the TC to make these
decisions was decided but was never implemented, and the second is still
pending before the TC, so the track record here is not great, for a
variety of reasons.)  But as matters stand right now, there's no way for
the Policy process to reach a conclusion on questions like this.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwi1kx36@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:
> Keith Packard writes:
>
>> That is an entirely separate issue. I agree that it is important and
>> needs to be resolved, but the Technical Committee is the wrong place to
>> be designing this policy. We must (by 6.3.5) not engage in design of new
>> proposals and policies.
>
> Well, in defense of the discussion that Steve, Colin, and I have been
> having, I do think it's worthwhile for the TC to try to hammer out a
> compromise on that point as well and express it as either technical advice
> to the project or as technical policy.

Why not hammer that out on -policy in public, and only if something
goes wrong there, then defer it to the TC?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPT=abtv+5vpe9aevqq3hivpl6xk3e1yr6-n+x5htv...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Sat, 08 Feb 2014, Bdale Garbee wrote:
> - - - start ballot - - -
> 
> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be
> 
>   Dsystemd 
> 
>   Uupstart
> 
>   Oopenrc
> 
>   Vsysvinit (no change)
> 
>   Frequires further discussion
> 
> 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.
> 
> - - - end ballot - - -

I vote D > U > O > V > F.

I also agree that given that while the additional questions of how
packages are able to depend or rely on the default init system is
important, it is not necessary to resolve that question to determine
which system is going to be the default init system, as in no ballot yet
has anyone changed their D/U ranking on the basis of which of the T, S,
or L options were being voted for.

-- 
Don Armstrong  http://www.donarmstrong.com

There is no form of lead-poisoning which more rapidly and thoroughly
pervades the blood and bones and marrow than that which reaches the
young author through mental contact with type metal.
 -- Oliver Wendell Holmes (Tilton 1947 p67)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140208225113.gl5...@teltox.donarmstrong.com

Re: Bug#727708: call for votes on default Linux init system for jessie

[Paul Tagliamonte]

On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
> I agree with Ian on this.  At this point, it should be clear to everyone
> that, given the stated preferences of each member of the TC, the default
> init system for jessie will be systemd.

Without an official vote we can *not* say this.

> But I do not think this is the most
> important aspect of the problem that needs to be decided. 

Perhaps not, but it was the problem that was escelated to the TC

> The question of
> how, or if, multiple init systems will coexist in the Debian archive for
> jessie is what needs to be decided in order to unblock maintainers and give
> them clarity for their own packages.

Why not let it to the maintainers to work through such issues, and
resolve it in the TC when and if that process breaks down, like every
other issue.

> The only thing that an "up/down" vote on init systems does is placate the
> crowds of onlookers who are not part of Debian's decision-making processes,
> at the expense of settling the more nuanced questions that need to be
> answered for the project.

The more nuanced question was not asked of the TC

> This should not be our priority.  Our purpose
> here is to make sound technical decisions on behalf of the project, not to
> preserve the TC's (or Debian's) "reputation" among third parties who have no
> legitimate say in the outcome.

At this point, it's blocking folks inside Debian, who are stakeholders.
It's not just the trolls of reddit and the internet, it's DDs who are
annoyed there's no decision and integration work isn't started. We're
less than a year from freeze.

[snip]

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

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Steve Langasek  writes:

> I agree with Ian on this.  At this point, it should be clear to everyone
> that, given the stated preferences of each member of the TC, the default
> init system for jessie will be systemd.  But I do not think this is the
> most important aspect of the problem that needs to be decided.  The
> question of how, or if, multiple init systems will coexist in the Debian
> archive for jessie is what needs to be decided in order to unblock
> maintainers and give them clarity for their own packages.

Given that you feel like it's clear what the default init system will be,
and given that the previous rounds of partial voting show that the choice
of dependency models will have no effect on that outcome, I don't see any
point in delaying this part of the decision.  You feel like this is all
but decided; fine, let's decide it, so that we have a decision on record,
and then continue the discussion.

Or, put another way, why *don't* you want to vote on this right now?  That
it's not the most important question is not a reason to delay voting on
it; if anything, it's a reason to vote on it first, so that we can dispose
of the questions with clear answers while we're working on language for
the more complex options.

We held the ballot to entangle it with other questions on the assumption
that this entangling may change the result for the primary question.  It
turns out that this is not the case, so there was no need for that
entangling.  I would really like to establish things that you think are
already apparent so that we have some forward progress and so that we
don't have to hold open sockets for things that we think are *probably*
decided but that we've not yet actually decided.

If you feel like deciding this will mean losing some momentum on a
question that you consider more important, I personally commit to
continuing the discussions on that process and working on a ballot and
arriving at a decision as quickly as possible.  I don't think any of us
intend to abandon this discussion once the init system default on Linux is
decided.

> I will note for the record here that a number of DDs have at this point
> given the TC an ultimatum in private, stating that they will start a GR
> if the TC does not call for votes within a specified time limit.  I
> suspect that this ultimatum didn't have much effect on Bdale's decision
> to call for a vote (since he was already predisposed to having the
> up/down vote in question).  Likewise, such an ultimatum doesn't change
> my view about what ballot should be voted and when.  And every DD has a
> constitutional right to start a GR on this question, at any point.  But
> it's highly inappropriate to attempt to pressure the TC into making a
> quick decision using the *threat* of a GR.  TC decisions take time
> precisely because they deal with nuanced issues that don't get handled
> any other way.  Rushing to a vote only delays efforts to reach a
> consensus in the project, and is counter to the long-term health of
> Debian.

I think a group of DDs are telling us that we're not doing our job in a
timely fashion.  While one may or may not agree with that, I think it's
intended as constructive feedback, and personally I welcome the
accountability to the rest of the project here.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877g95me4s@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Walter Alejandro Iglesias]

My first and last message to this list.

To Those Who Understand
---

Time ago, Linux was conceived as a Unix like OS.  Thanks to internet it won
acceptance between hackers familiarized with Unix, guys that liked and valued
to have a Unix like OS at home.  That first enthusiasm made Linux grow to the
point some big companies put their eyes on it.  Linux started to be popular and
the dichotomy appeared.  The big public has no interest in command line
interface, the crowd has no interest in learning how to administering a Unix
like OS and learn all that shell scripting.  Read and write is annoying;
welcome to modernity.  What the crowd wants is fancy WYSIWYG friendly
interfaces (even in server machines), like in Windows, what the crowd wants is
fancy pop up notifications like in Windows, devices recognized and mounted on
the fly like in Windows, a fancy full resolution image with a progress bar
while booting, like in Windows.  Well, big companies sell what the crowd buy,
that's why they are big.  The modifications made in the name of *modernity* (to
give a Windows like OS to the crowd) that time ago just affected userland now
took the base system, init system and the kernel.  Like we all knew from the
first time, finally the cancer took the whole body.

Just the few that understand and value the idea behind Unix see the loss this
means to everybody.  But we are a minority, who cares? ;-)


To Those Who Don't Understand
-

Do you think on another OS while using Linux?  (does your wife think on another
man while having sex with you?)  Envy makes the world go round.

All the spaghetti code you see on most big Linux distributions is not sysv-init
fault.  Any doubt?  Give a try to Crux Linux (I mention Crux like an example,
not propaganda), read its rc files and see how it boots and you won't want to
hear about systemd/upstart tales anymore.

That you don't want to read and write bash scripts?  If you don't want to get
your hands dirty why do you use FOSS?


Walter




-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206131418.GA5062@lenovo.local

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Josh Triplett writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> That is a very interesting clarification, and not one that seems at all
> obvious from the text of 'L'.  'L' talks about "Software outside of an init
> system's implementation", which does not seem like it would extend to
> "management guis or addons".

I think it depends what you think of as an init system's
"implementation".  I would include the utilities you use to manage it.

> So, for instance, GNOME Logs, a new upstream project specifically
> designed to browse the systemd journal, could by the clarification above
> be considered part of the init system, and thus can depend on it?

I haven't looked at that in detail.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett]

Ian Jackson wrote:
> Anthony Towns writes ("Bug#727708: call for votes on default Linux init 
> system for jessie"):
> > So looking at the votes today, I would have said that both Ian and
> > Andi's original votes are against this (ranking the options which
> > allow specifying a dependency on a specific init below further
> > discussion), and probably Steve's does too, although I assume that's
> > more an objection against the wording.
> > 
> > At least, the impact seems like it is:
> > 
> >  - init systems can provide whatever extra APIs they like
> >  - other packages can only use extra APIs if they have a dependency on
> > the providing package
> >  - packages may not depend on specific init systems
> > 
> >  * therefore packages cannot use the extra APIs
> 
> (In the L options:) Yes, packages which aren't part of the init system
> aren't allowed to depend on those extra APIs.
> 
> But packages which _are_ part of the init system are so allowed.
> (Think, for example, management guis or addons for a particular init
> system.)  Answering "no" to the question Q2a above would have
> forbidden that.

That is a very interesting clarification, and not one that seems at all
obvious from the text of 'L'.  'L' talks about "Software outside of an init
system's implementation", which does not seem like it would extend to
"management guis or addons".

So, for instance, GNOME Logs, a new upstream project specifically
designed to browse the systemd journal, could by the clarification above
be considered part of the init system, and thus can depend on it?

If so, I would be very interested in further clarifications regarding
what it takes to be considered part of an init system.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206121515.GA6648@leaf

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Anthony Towns writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> On 29 January 2014 21:13, Colin Watson  wrote:
> > On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> >> >   Q2: Is it OK for packages to depend on a specific init system as
> >> >   pid 1 ?
> >>   Q2a: Is it OK for packages providing init systems to provide other
> >> APIs beyond just the minimum needed for starting/stopping services?
> > We might disagree on the extent, perhaps, but I doubt anyone on the
> > committee would vote against this in its general form;

This just goes to show how the exact form of words used can be
confusing or misleading.

> So looking at the votes today, I would have said that both Ian and
> Andi's original votes are against this (ranking the options which
> allow specifying a dependency on a specific init below further
> discussion), and probably Steve's does too, although I assume that's
> more an objection against the wording.
> 
> At least, the impact seems like it is:
> 
>  - init systems can provide whatever extra APIs they like
>  - other packages can only use extra APIs if they have a dependency on
> the providing package
>  - packages may not depend on specific init systems
> 
>  * therefore packages cannot use the extra APIs

(In the L options:) Yes, packages which aren't part of the init system
aren't allowed to depend on those extra APIs.

But packages which _are_ part of the init system are so allowed.
(Think, for example, management guis or addons for a particular init
system.)  Answering "no" to the question Q2a above would have
forbidden that.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett]

Anthony Towns wrote:
> On 29 January 2014 21:13, Colin Watson  wrote:
> > On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> >> >   Q2: Is it OK for packages to depend on a specific init system as
> >> >   pid 1 ?
> >>   Q2a: Is it OK for packages providing init systems to provide other
> >> APIs beyond just the minimum needed for starting/stopping services?
> > We might disagree on the extent, perhaps, but I doubt anyone on the
> > committee would vote against this in its general form;
> 
> So looking at the votes today, I would have said that both Ian and
> Andi's original votes are against this (ranking the options which
> allow specifying a dependency on a specific init below further
> discussion), and probably Steve's does too, although I assume that's
> more an objection against the wording.
> 
> At least, the impact seems like it is:
> 
>  - init systems can provide whatever extra APIs they like
>  - other packages can only use extra APIs if they have a dependency on
> the providing package
>  - packages may not depend on specific init systems
> 
>  * therefore packages cannot use the extra APIs

I agree with your conclusion on the practical effect here.

I'm also amused that exactly the same logic readily applies at the next
level down, to an init system making use of APIs and functionality that
Linux has and other systems do not.  In both cases, the question is the
same: least common denominator, or actually using available
functionality?

(To forestall the obvious objection: "optional" is the same as "least
common denominator", in that it effectively prevents *relying* on that
functionality, and thus forces the creation of a
least-common-denominator fallback, which everything higher in the stack
must then cope with.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206070218.GA829@leaf

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

Hey Colin,

On 29 January 2014 21:13, Colin Watson  wrote:
> On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
>> >   Q2: Is it OK for packages to depend on a specific init system as
>> >   pid 1 ?
>>   Q2a: Is it OK for packages providing init systems to provide other
>> APIs beyond just the minimum needed for starting/stopping services?
> We might disagree on the extent, perhaps, but I doubt anyone on the
> committee would vote against this in its general form;

So looking at the votes today, I would have said that both Ian and
Andi's original votes are against this (ranking the options which
allow specifying a dependency on a specific init below further
discussion), and probably Steve's does too, although I assume that's
more an objection against the wording.

At least, the impact seems like it is:

 - init systems can provide whatever extra APIs they like
 - other packages can only use extra APIs if they have a dependency on
the providing package
 - packages may not depend on specific init systems

 * therefore packages cannot use the extra APIs

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJS_LCVyWXwTGjK0K=pooaz+pvvngrbxu1_rcblz7h6079x...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett]

Steve Langasek wrote:
> On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote:
> > Bdale Garbee  writes:
> 
> > > Thus, I believe the only acceptable option for Q2 from among your set is
> > > "requiring a specific init is permitted even if it is not the default
> > > one".  But I would prefer to vote a ballot that doesn't mention
> > > dependencies at all.
> 
> > I agree with this; I don't think we should try to force developers into
> > significant work to satisfy an init system constraint as that may
> > prevent or delay important fixes and improvements from entering the
> > repository.
> 
> > Of course, nothing would prevent someone else from fixing these kinds of
> > bugs and having those fixes get merged into the package, potentially
> > invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
> > However, I'd anticipate that most package developers would readily
> > accept fixes that made their packages work for more people.
> 
> I'd like to believe this; however, the fact that bug #726763 is still open
> leads me to fear otherwise.

I don't see any counterexamples in 726763 to the statement that "nothing
would prevent someone else from fixing these kinds of bugs and having
those fixes get merged into the package", or to the statement that "most
package developers would readily accept fixes that made their packages
work for more people."  Fixing 726763 just needs a "Depends" from the
GNOME packages to reflect their dependency on logind and the suspend
inhibit mechanism, which as stated in the bug log won't happen until the
resolution of 727708.  Meanwhile, installing either systemd-sysv or
systemd-shim (or having systemd installed and booting with
init=/bin/systemd) fixes the issue reported in 726763.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140201201507.GA13442@leaf

Bug#727708: call for votes on default Linux init system for jessie

[Steve Langasek]

On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote:
> Bdale Garbee  writes:

> > Thus, I believe the only acceptable option for Q2 from among your set is
> > "requiring a specific init is permitted even if it is not the default
> > one".  But I would prefer to vote a ballot that doesn't mention
> > dependencies at all.

> I agree with this; I don't think we should try to force developers into
> significant work to satisfy an init system constraint as that may
> prevent or delay important fixes and improvements from entering the
> repository.

> Of course, nothing would prevent someone else from fixing these kinds of
> bugs and having those fixes get merged into the package, potentially
> invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
> However, I'd anticipate that most package developers would readily
> accept fixes that made their packages work for more people.

I'd like to believe this; however, the fact that bug #726763 is still open
leads me to fear otherwise.

-- 
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

Bug#727708: call for votes on default Linux init system for jessie

[Sergey B Kirpichev]

(I was informed, that my posts are not welcome anymore here.  So,
there is last one for all.)

On Thu, Jan 30, 2014 at 12:05:19PM -0700, Bdale Garbee wrote:
> Sergey B Kirpichev  writes:
> > I just wonder why nobody from tect-ctte take care about the exact
> > specification of that "bare minimum" (or, in other words, what exactly
> > is wrong with sysvinit).
> 
> In a sense, we all have done this, even if you don't see it explicitly
> written in just this way.

Sorry.  Maybe it's clear from the thread for others, that this
specification is somewhere in minds of all tech-ctte members...

But I doubt if it's so, as I was kindly pointed out to
https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
Is this all (what we want to fix in sysvinit/what we want to have
in the modern init)?

And that wasn't clear for others, otherwise I can't explain, for example,
the questions why OpenRC was silently discarded from reviews.

> The thing that may not be obvious is that this line doesn't stand still,
> it is constantly moving as more people develop more free software that
> does newer and better things and in the process builds new dependencies.

Old init was working for years.  Are we only buy something
that satisfy the new dependencies (for the Gnome) or a new
init, that would work for comparable time?

On Thu, Jan 30, 2014 at 05:16:46PM -0800, Keith Packard wrote:
> In effect, X takes the Debian position that patches which improve
> interoperabilty with a specific init system should be integrated.

Seems to be sane and reasonable position.  I wonder why Gnome
people can't follow this.

>> Where is the list of problems for sysvinit we intend to solve?
> For X, the problem is running X as a user other than root

(There are sysvinit-enabled setups even without X...)

On Fri, Jan 31, 2014 at 09:38:45AM +0100, Josselin Mouette wrote:
> > > https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
> Since you forgot to paste the first sentence, let me add it here.
> 
> “Sysvinit was never designed to cope with the dynamic/event-based
> architecture of the current Linux kernel. The only reason why we still
> use it today is the cost of a migration.”

I'm not forgot, because it's not the only reason - please
see the mentioned example.

> Anyone who knows how Linux works doesn’t consider
> sysvinit a viable choice today.

I'm sure Google sysadmins know how Linux works, still
they consider sysvinit to be a viable (and preferred) choice.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140131100713.ga13...@darkstar.order.hcn-strela.ru

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Sergey B Kirpichev  writes:

> I just wonder why nobody from tect-ctte take care about the exact
> specification of that "bare minimum" (or, in other words, what exactly
> is wrong with sysvinit).

In a sense, we all have done this, even if you don't see it explicitly
written in just this way.  

The thing that may not be obvious is that this line doesn't stand still,
it is constantly moving as more people develop more free software that
does newer and better things and in the process builds new dependencies.

Bdale


pgpg2HS7DQrLT.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Sergey B Kirpichev]

On Wed, Jan 29, 2014 at 11:13:33AM +, Colin Watson wrote:
> We might disagree on the extent, perhaps, but I doubt anyone on the
> committee would vote against this in its general form; both systemd and
> upstart implement interfaces beyond the bare minimum, though upstart
> certainly takes a more minimalist tack.

I just wonder why nobody from tect-ctte take care about the exact
specification of that "bare minimum" (or, in other words, what exactly
is wrong with sysvinit).  Correct me, please, if I'm wrong.

The whole 3000+ thread is about different features of one or another
sysvinit replacement.  Or do we buy the least terrible variant from the 
submitted?


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140130104009.ga10...@darkstar.order.hcn-strela.ru

Bug#727708: call for votes on default Linux init system for jessie

[Steven Chamberlain]

On 19:01, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
> > What makes you think gnome is going to be the default?
> > 
> > http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
> 
> Read the text in debian/changelog that is there - the final decision 
> will be made in August (or later).
> 
> I was sarcastically describing a worst-case scenario that is not 
> completely impossible - in reality I would expect enough sanity
> in Debian to ensure that something depending on a non-default
> init system cannot be part of a default installation.

I'd expect Debian GNOME install media would still give a GNOME desktop
by default, Debian KDE disc gives you KDE, etc.

Would it be crazy to suggest putting the preferred init system
in the 'task'?  A Debian GNOME install would likely install systemd,
otherwise it could be something else.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129172039.gb21...@squeeze.pyro.eu.org

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote:
> On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
> > For anyone intending to make Debian the laughingstock of the open source
> > world, here is a good opportunity:
> >
> >   Debian decides that Upstart is the default init system for jessie,
> >   but it's default desktop GNOME forces the installation of systemd.
> 
> What makes you think gnome is going to be the default?
> 
> http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5

Read the text in debian/changelog that is there - the final decision 
will be made in August (or later).

I was sarcastically describing a worst-case scenario that is not 
completely impossible - in reality I would expect enough sanity
in Debian to ensure that something depending on a non-default
init system cannot be part of a default installation.

> Best wishes,
> Mike

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129170154.gb5...@bunk.dyndns.info

Bug#727708: call for votes on default Linux init system for jessie

[Colin Watson]

On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> On 28 January 2014 21:39, Ian Jackson  wrote:
> > I don't want to pass a resolution specifying the default without also
> > answering the other two, related, contentious questions:
> >   Q1: Do we intend to support multiple systems long-term, or do we
> >   intend to settle on a single system, probably in jessie+1 ?
> 
> FWIW, that seems overly prescriptive to me -- if we settle on systemd
> now, and as a result upstart stops getting maintained and systemfree
> gets written that uses the same config files but only works on FreeBSD
> and Hurd, maybe no one will want to maintain multiple init systems
> later.

Perhaps a better phrasing would be something like "remain open to
supporting multiple init systems as long as they are actively
maintained".

> Conversely, maybe people get excited about some init system we
> don't pick as default for jessie and it becomes really awesome by the
> time jessie is out; why would we want to prevent it being available in
> Debian even if it's not ready to be default, or doesn't work with
> Gnome yet, or whatever?

(I don't think I can suggest better wording for the "single" options as
they aren't ones I favour.)

> >   Q2: Is it OK for packages to depend on a specific init system as
> >   pid 1 ?
> 
> I don't think that's the right question for the issue(s) at play here.
> 
> >From what I can tell, the important question isn't whether systemd or
> upstart happens to be pid 1, but rather whether certain interfaces
> (dbus, logind, potentially others) that are only (currently) provided
> by systemd are available on the system.

That's certainly the principal issue for e.g. GNOME.  But I think it's
reasonable to anticipate that some maintainers might want to drop
support in their service packages for init systems which they don't
favour and which aren't the default; one can reasonably take different
views on whether that's appropriate, and I think guidance from the
committee would be useful.

I agree with you that it's worth breaking it down into the matters of
service specifications (which for the most part have resisted attempts
to implement translation layers) and other APIs (which have a better
track record here).

>   Q2a: Is it OK for packages providing init systems to provide other
> APIs beyond just the minimum needed for starting/stopping services?

We might disagree on the extent, perhaps, but I doubt anyone on the
committee would vote against this in its general form; both systemd and
upstart implement interfaces beyond the bare minimum, though upstart
certainly takes a more minimalist tack.

> After Steve's and Russ's comments in [0] and [1], and thinking about
> it some more, I'm inclined to think all those questions could
> reasonably be dealt with through the policy process, though I still
> think some non-binding advice from the tech ctte wouldn't be out of
> place.

I certainly don't think we should get into the specifics of how things
should be laid out, but the general direction is non-obvious and
important.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129111333.ga14...@riva.ucam.org

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
> For anyone intending to make Debian the laughingstock of the open source
> world, here is a good opportunity:
>
>   Debian decides that Upstart is the default init system for jessie,
>   but it's default desktop GNOME forces the installation of systemd.

What makes you think gnome is going to be the default?

http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mm4n_6ae8w-dyqph-ph3ry0co2tm9jbb_+vh+mn+jr...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 28 January 2014 21:39, Ian Jackson  wrote:
> I don't want to pass a resolution specifying the default without also
> answering the other two, related, contentious questions:
>   Q1: Do we intend to support multiple systems long-term, or do we
>   intend to settle on a single system, probably in jessie+1 ?

FWIW, that seems overly prescriptive to me -- if we settle on systemd
now, and as a result upstart stops getting maintained and systemfree
gets written that uses the same config files but only works on FreeBSD
and Hurd, maybe no one will want to maintain multiple init systems
later. Conversely, maybe people get excited about some init system we
don't pick as default for jessie and it becomes really awesome by the
time jessie is out; why would we want to prevent it being available in
Debian even if it's not ready to be default, or doesn't work with
Gnome yet, or whatever?

>   Q2: Is it OK for packages to depend on a specific init system as
>   pid 1 ?

I don't think that's the right question for the issue(s) at play here.

>From what I can tell, the important question isn't whether systemd or
upstart happens to be pid 1, but rather whether certain interfaces
(dbus, logind, potentially others) that are only (currently) provided
by systemd are available on the system.

That would make the question break down into something like:

  Q2a: Is it OK for packages providing init systems to provide other
APIs beyond just the minimum needed for starting/stopping services?

  Q2b: If so, is it OK for packages requiring those APIs (such as
logind) to just depend on the particular init system known to provide
them (eg Depends: systemd)?

There's a third related question that I don't think is particularly
crucial, regarding the different ways of telling different init
systems about your service:

  Q2c: Is it OK for packages to provide a service start/stop
description that is understandable by some but not all available init
systems in Debian?

After Steve's and Russ's comments in [0] and [1], and thinking about
it some more, I'm inclined to think all those questions could
reasonably be dealt with through the policy process, though I still
think some non-binding advice from the tech ctte wouldn't be out of
place.

[0] https://lists.debian.org/debian-ctte/2014/01/msg00382.html
[1] https://lists.debian.org/debian-ctte/2014/01/msg00383.html

>  Q2: Requiring specific init is forbidden

Note that this answer would preclude providing a package designed to,
say, "duplicate aj's environment exactly, because it's awesome and all
his friends want to just be able to apt-get install it and be just as
cool as aj is". I don't think that's a win.

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajs_lcxhqy5ubbtm6s9pujagdos_uxkjqbd9lxhmrvfstr-...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Uoti Urpala]

On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
> On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > > The former. So :
> > > > 
> > > >Where feasible, software should interoperate with non-default init
> > > >systems; maintainers are encouraged to accept technically sound
> > > >patches to enable interoperation, even if it results in degraded
> > > >operation while running under the non-default init.
> > >
> > > Maybe I'm dense...
> > > 
> > > Scenario: Let's say that OpenRC is the new default init and in the
> > > meanwhile, Gnome has gained a dependency on systemd. A patch to
> > > support Upstart in Gnome is posted that partially breaks the
> > > functionality under systemd.
> > > 
> > > By your wording, maintainers are encouraged to accept the patch.
> > 
> > No. This was precisely the ambiguity which Neil (correctly) pointed out.
> > Simply put, patches which reduced existing functionality while running
> > under the default init (say, systemd), would not be technically sound.
> > 
> > Instead, maintainers are encouraged to accept the patch even if it
> > results in reduced functionality while running under the non-default
> > init (say, upstart) in comparison to the default init (say, systemd).
> 
> That's a different case.
> 
> Zbigniew was talking about a package that has a dependency on a
> *non*default init system.
> 
> And for that the first question is whether such a dependency on a 
> *non*default init would be allowed at all.

Not really. What Zbigniew was talking about was whether the above
wording would allow a patch enabling operation with system A to degrade
existing functionality with *another* system B (whether B is actually a
strict "dependency" does not seem that important). This depends on how
you interpret "the non-default init"; Don obviously meant this to refer
to the same init as the patch is for.

I think this kind of possible ambiguity could be avoided by phrasing
like "even if the patch only implements a degraded mode of operation
under this system", to make it clear that the "degrade" does not refer
to any functionality that existed _before_ the patch.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1390942291.4304.222.camel@glyph.nonexistent.invalid

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Adrian Bunk wrote:
> Zbigniew was talking about a package that has a dependency on a
> *non*default init system.

Ah, OK. That's easily resolved with 

Where feasible, software should interoperate with non-default init
systems; maintainers are encouraged to accept technically sound
patches to enable interoperation, even if it results in degraded
operation while running under the init system the patch enables
interoperation with.

> And for that the first question is whether such a dependency on a
> *non*default init would be allowed at all.

I'm deliberately avoiding even wading into this question, because
delineating between packages whose design requires that they depend on a
specific init system, packages which depend on a particular init system
due to a lack of developer effort, and packages which depend on a
particular init system for no good reason at all is hard.

I'd much rather give some guidance (in the form of the above), and trust
maintainers to do the right thing. The CTTE and/or the project can
always intervene if necessary after the fact.

-- 
Don Armstrong  http://www.donarmstrong.com

"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence."
 -- Jeremy S. Anderson


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128204943.go2...@rzlab.ucr.edu

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > > The former. So :
> > > 
> > >Where feasible, software should interoperate with non-default init
> > >systems; maintainers are encouraged to accept technically sound
> > >patches to enable interoperation, even if it results in degraded
> > >operation while running under the non-default init.
> >
> > Maybe I'm dense...
> > 
> > Scenario: Let's say that OpenRC is the new default init and in the
> > meanwhile, Gnome has gained a dependency on systemd. A patch to
> > support Upstart in Gnome is posted that partially breaks the
> > functionality under systemd.
> > 
> > By your wording, maintainers are encouraged to accept the patch.
> 
> No. This was precisely the ambiguity which Neil (correctly) pointed out.
> Simply put, patches which reduced existing functionality while running
> under the default init (say, systemd), would not be technically sound.
> 
> Instead, maintainers are encouraged to accept the patch even if it
> results in reduced functionality while running under the non-default
> init (say, upstart) in comparison to the default init (say, systemd).

That's a different case.

Zbigniew was talking about a package that has a dependency on a
*non*default init system.

And for that the first question is whether such a dependency on a 
*non*default init would be allowed at all.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128202012.ga22...@bunk.dyndns.info

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> > The former. So :
> > 
> >Where feasible, software should interoperate with non-default init
> >systems; maintainers are encouraged to accept technically sound
> >patches to enable interoperation, even if it results in degraded
> >operation while running under the non-default init.
>
> Maybe I'm dense...
> 
> Scenario: Let's say that OpenRC is the new default init and in the
> meanwhile, Gnome has gained a dependency on systemd. A patch to
> support Upstart in Gnome is posted that partially breaks the
> functionality under systemd.
> 
> By your wording, maintainers are encouraged to accept the patch.

No. This was precisely the ambiguity which Neil (correctly) pointed out.
Simply put, patches which reduced existing functionality while running
under the default init (say, systemd), would not be technically sound.

Instead, maintainers are encouraged to accept the patch even if it
results in reduced functionality while running under the non-default
init (say, upstart) in comparison to the default init (say, systemd).

-- 
Don Armstrong  http://www.donarmstrong.com

I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
 -- Patrick McGoohan as Number 6 in "The Prisoner"


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128200819.gl2...@rzlab.ucr.edu

Bug#727708: call for votes on default Linux init system for jessie

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Neil McGovern wrote:
> > On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
> > >   Where feasible, software should interoperate with non-default init
> > >   systems; maintainers are encouraged to accept technically sound
> > >   patches to enable interoperation, even if it results in degraded
> > >   operation.
> > > 
> > 
> > Did you mean "degraded operation while running under the non-default
> > init." or "degraded operation while running under the default init."?
> 
> The former. So :
> 
>Where feasible, software should interoperate with non-default init
>systems; maintainers are encouraged to accept technically sound
>patches to enable interoperation, even if it results in degraded
>operation while running under the non-default init.
Maybe I'm dense...

Scenario: Let's say that OpenRC is the new default init and in the
meanwhile, Gnome has gained a dependency on systemd. A patch to
support Upstart in Gnome is posted that partially breaks the
functionality under systemd.

By your wording, maintainers are encouraged to accept the patch.

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128194642.gh...@in.waw.pl

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Neil McGovern wrote:
> On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
> >   Where feasible, software should interoperate with non-default init
> >   systems; maintainers are encouraged to accept technically sound
> >   patches to enable interoperation, even if it results in degraded
> >   operation.
> > 
> 
> Did you mean "degraded operation while running under the non-default
> init." or "degraded operation while running under the default init."?

The former. So :

   Where feasible, software should interoperate with non-default init
   systems; maintainers are encouraged to accept technically sound
   patches to enable interoperation, even if it results in degraded
   operation while running under the non-default init.

-- 
Don Armstrong  http://www.donarmstrong.com

If you find it impossible to believe that the universe didn't have a
creator, why don't you find it impossible that your creator didn't
have one either?
 -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556&cid=13970629


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128192311.gg2...@rzlab.ucr.edu

Bug#727708: call for votes on default Linux init system for jessie

[Neil McGovern]

Hi Don,

On Tue, Jan 28, 2014 at 11:05:18AM -0800, Don Armstrong wrote:
>   Where feasible, software should interoperate with non-default init
>   systems; maintainers are encouraged to accept technically sound
>   patches to enable interoperation, even if it results in degraded
>   operation.
> 

Did you mean "degraded operation while running under the non-default
init." or "degraded operation while running under the default init."?

I suspect the former, but perhaps a wording tweak for clarity may be
useful :)

Neil


signature.asc
Description: Digital signature

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Ian Jackson wrote:
> Don Armstrong writes ("Bug#727708: call for votes on default Linux init 
> system for jessie"):
> > On Tue, 28 Jan 2014, Ian Jackson wrote:
> > > >M. Debian intends to support multiple init systems, for the
> > > >   foreseeable future, and so long as their respective communities
> > > >   and code remain healthy.  Software outside of an init system's
> > > >   implementation may not require a specific init system to be
> > > >   pid 1, although degraded operation is tolerable.
> > 

[...]

> Is there some rephrasing of this paragraph which would persuade you to
> put it ahead of a ballot option with the paragraph entirely deleted ?

Changing the last sentence to 

  Where feasible, software should interoperate with non-default init
  systems; maintainers are encouraged to accept technically sound
  patches to enable interoperation, even if it results in degraded
  operation.

would be enough for me, but that basically makes the entire sentence
advisory, which probably doesn't satisfy your concerns.

-- 
Don Armstrong  http://www.donarmstrong.com

You think to yourself, hey, it's a test tube, for God's sake. Pretty
soon, though, the rush from a test tube isn't enough. You want to
experiment more and more. Then before you know it, you're laying in
the corner of a lab somewhere with a Soxhlet apparatus in one hand,
a three neck flask in the other, strung out and begging for grant
money.
 -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128190518.gc2...@rzlab.ucr.edu

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:
>> Ian Jackson  writes:

>>> Of these (ii) would cause the non-default inits to rot.  Unless anyone
>>> thinks this is a useful option I don't think we should vote on it.

>> ii is my preferred option.  I think it's the option that makes the most
>> sense.  I don't agree that it will necessarily cause non-default inits
>> to rot.

> Do you agree with Russ and Bdale that it would be better not to address
> these questions in the TC decision ?

Yes, that's even better.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5200wxz@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Ian Jackson writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> Do you agree with Russ and Bdale that it would be better not to

Wait, where did "Russ" come from there ?  I meant Keith.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Russ Allbery writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> Ian Jackson  writes:
> > Of these (ii) would cause the non-default inits to rot.  Unless anyone
> > thinks this is a useful option I don't think we should vote on it.
> 
> ii is my preferred option.  I think it's the option that makes the most
> sense.  I don't agree that it will necessarily cause non-default inits to
> rot.

Do you agree with Russ and Bdale that it would be better not to
address these questions in the TC decision ?  If so then I don't think
we need to explore this line of conversation any further; it's only
worth it if there is a form of words that you would prefer to saying
nothing at all.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Russ Allbery]

Ian Jackson  writes:

> I think there are the following three reasonable answers to Q1/Q2
> taken together.

> i.   Q1: Multiple in >jessie
>  Q2: Requiring specific init is forbidden

> ii.  Q1: Multiple in >jessie
>  Q2: Requiring default init is permitted

> iii. Q1: Single in jessie+1
>  Q2: Requiring default init is permitted

> Of these (ii) would cause the non-default inits to rot.  Unless anyone
> thinks this is a useful option I don't think we should vote on it.

ii is my preferred option.  I think it's the option that makes the most
sense.  I don't agree that it will necessarily cause non-default inits to
rot.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877g9k2bwt@windlord.stanford.edu

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Adrian Bunk  writes:

>   Debian decides that Upstart is the default init system for jessie,
>   but it's default desktop GNOME forces the installation of systemd.

There are reasons I've left gnome behind...

-- 
keith.pack...@intel.com


pgpud6GoOLbVe.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Don Armstrong writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> On Tue, 28 Jan 2014, Ian Jackson wrote:
> > >M. Debian intends to support multiple init systems, for the
> > >   foreseeable future, and so long as their respective communities
> > >   and code remain healthy.  Software outside of an init system's
> > >   implementation may not require a specific init system to be
> > >   pid 1, although degraded operation is tolerable.
> 
> I still don't think the last sentence of this paragraph completely
> handles the cases where someone can legitimately depend on a specific
> init system or specific init system interface.
> 
> If we're supporting multiple init systems, then software which doesn't
> support multiple init systems which could feasibly do so is buggy. If
> patches to fix it appear and aren't applied, then people can appeal to
> the CTTE. It's not necessary or feasible for us to anticipate every
> single technical wrinkle and delay making a decision to do so.

Is there some rephrasing of this paragraph which would persuade you to
put it ahead of a ballot option with the paragraph entirely deleted ?

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie [and 1 more messages]

[Ian Jackson]

Bdale Garbee writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> Thus, I believe the only acceptable option for Q2 from among your set is
> "requiring a specific init is permitted even if it is not the default
> one".  But I would prefer to vote a ballot that doesn't mention
> dependencies at all. 

Keith Packard writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> I'm still very uncomfortable with any vote that would constrain our
> solution space past the Jessie release. I'm fairly convinced that we'll
> be supporting multiple init systems for a long time, but my vision gets
> very fuzzy out that far, and it's just possible I might be wrong.

I'm not going to try to talk you out of this.

In that case we need options on the ballot which don't contain any of
the texts on this question I was proposing, as well as options why do.

If there is noone who wants to explicitly say something like this

O. Debian intends to converge on one init system; in jessie+1,
   packages may require that the default init system is in use.

then there is no point putting it on the ballot.

That would leave us with

DM  systemd by default, but also others
D-  systemd by default, say nothing else
UM  upstart by default, but also others
U-  upstart by default, say nothing else
R-  openrc by default, say nothing else
V-  sysvinit by default, say nothing else

I'm not going to push for RM and RV even though I would prefer them,
because I think R- and V- are more popular in the rest of the TC.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Jan 28, 2014 at 09:12:54AM -0800, Keith Packard wrote:
> Ian Jackson  writes:
> 
> > I think it doesn't make sense to allow people to require a non-default
> > init.
> 
> I think this position is consistent with allowing each maintainer broad
> autonomy, and not overly burdening them with requirements that may make
> it difficult or impossible to provide bug fixes and other improvements
> From newer upstream versions.
> 
> Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
> RC bug.

For anyone intending to make Debian the laughingstock of the open source
world, here is a good opportunity:

  Debian decides that Upstart is the default init system for jessie,
  but it's default desktop GNOME forces the installation of systemd.


> Ian.

cu
Adrian

BTW: Yes, the "default desktop for jessie" discussion that is scheduled 
 for August is also intertwingled with the init system issue...

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128174232.gc18...@bunk.dyndns.info

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Ian Jackson  writes:

> If we are I to vote now, I would like to see on the ballot at least:
>DM  systemd by default, but also others
>DO  systemd only in jessie+1
>UM  upstart by default, but also others
>UO  upstart only in jessie+1
>RM  openrc by default, but also others
>VM  sysvinit by default, but also others

I'm still very uncomfortable with any vote that would constrain our
solution space past the Jessie release. I'm fairly convinced that we'll
be supporting multiple init systems for a long time, but my vision gets
very fuzzy out that far, and it's just possible I might be wrong.

-- 
keith.pack...@intel.com


pgpKuKTa8rX3Y.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Adrian Bunk]

On Tue, Jan 28, 2014 at 11:39:51AM +, Ian Jackson wrote:
>...
>M. Debian intends to support multiple init systems, for the
>   foreseeable future, and so long as their respective communities
>   and code remain healthy.  Software outside of an init system's
>   implementation may not require a specific init system to be
>   pid 1, although degraded operation is tolerable.
>...

Is udev considered to be part of systemd's implementation?


> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128173556.gb18...@bunk.dyndns.info

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Bdale Garbee  writes:

> Thus, I believe the only acceptable option for Q2 from among your set is
> "requiring a specific init is permitted even if it is not the default
> one".  But I would prefer to vote a ballot that doesn't mention
> dependencies at all.

I agree with this; I don't think we should try to force developers into
significant work to satisfy an init system constraint as that may
prevent or delay important fixes and improvements from entering the
repository.

Of course, nothing would prevent someone else from fixing these kinds of
bugs and having those fixes get merged into the package, potentially
invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
However, I'd anticipate that most package developers would readily
accept fixes that made their packages work for more people.

-- 
keith.pack...@intel.com


pgpqxdKZwFmK0.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Ian Jackson  writes:

> I think it doesn't make sense to allow people to require a non-default
> init.

I think this position is consistent with allowing each maintainer broad
autonomy, and not overly burdening them with requirements that may make
it difficult or impossible to provide bug fixes and other improvements
From newer upstream versions.

Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
RC bug.

-- 
keith.pack...@intel.com


pgpMPBm_vJZcg.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> I think it doesn't make sense to allow people to require a non-default
> init.  If you think it does then there are three possible answers to
> Q2: "requiring a specific init is permitted even if it is not the
> default one", "requiring the default init is OK but requiring another
> is not" and "requiring a specific init is not OK".

I prefer Don's approach to thinking about this:

   I still don't think the last sentence of this paragraph completely
   handles the cases where someone can legitimately depend on a specific
   init system or specific init system interface.

   If we're supporting multiple init systems, then software which doesn't
   support multiple init systems which could feasibly do so is buggy. If
   patches to fix it appear and aren't applied, then people can appeal to
   the CTTE. It's not necessary or feasible for us to anticipate every
   single technical wrinkle and delay making a decision to do so.

Thus, I believe the only acceptable option for Q2 from among your set is
"requiring a specific init is permitted even if it is not the default
one".  But I would prefer to vote a ballot that doesn't mention
dependencies at all. 

Bdale


pgpvLLHZ1WLRG.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Bdale Garbee writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> Ian Jackson  writes:
> > I think there are the following three reasonable answers to Q1/Q2
> > taken together.
> >
> > i.   Q1: Multiple in >jessie
> >  Q2: Requiring specific init is forbidden
> >
> > ii.  Q1: Multiple in >jessie
> >  Q2: Requiring default init is permitted
> >
> > iii. Q1: Single in jessie+1
> >  Q2: Requiring default init is permitted
> 
> Why do you use 'specific init' in (1) but "default init" in (ii) and
> (iii)?  Please be consistent in the use of "specific init" for all three
> options.  

I think it doesn't make sense to allow people to require a non-default
init.  If you think it does then there are three possible answers to
Q2: "requiring a specific init is permitted even if it is not the
default one", "requiring the default init is OK but requiring another
is not" and "requiring a specific init is not OK".

> With that change, (ii) might well be my first choice among these three.

But I guess you disagree.

> As written, I don't see the point of having Q2 included in (iii) other
> than for completeness, as asserting that we'll only support one init
> system seems to make the question of whether anything depends on it
> explicitly irrelevant and/or redundant?

I was trying to determine the reasonable subset of the entire possible
matrix of answers.  Obviously I think the answer "single" to Q1
implies the "requiring the default init is OK" to Q2.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> I think there are the following three reasonable answers to Q1/Q2
> taken together.
>
> i.   Q1: Multiple in >jessie
>  Q2: Requiring specific init is forbidden
>
> ii.  Q1: Multiple in >jessie
>  Q2: Requiring default init is permitted
>
> iii. Q1: Single in jessie+1
>  Q2: Requiring default init is permitted

Why do you use 'specific init' in (1) but "default init" in (ii) and
(iii)?  Please be consistent in the use of "specific init" for all three
options.  

With that change, (ii) might well be my first choice among these three.

As written, I don't see the point of having Q2 included in (iii) other
than for completeness, as asserting that we'll only support one init
system seems to make the question of whether anything depends on it
explicitly irrelevant and/or redundant?

Bdale


pgpwFh0B82JPC.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Bdale Garbee]

Ian Jackson  writes:

> If we are I to vote now, I would like to see on the ballot at least:

If we choose to proceed with this kind of a vote, the combinations I
care about are adequately captured by this list. 

I remain uncomfortable, however, about trying to be prescriptive about
what happens past jessie. 

Bdale


pgpBV1IzetmAK.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Michael Gilbert]

On Tue, Jan 28, 2014 at 8:51 AM, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Ian Jackson wrote:
>>   Q1: Do we intend to support multiple systems long-term, or do we
>>   intend to settle on a single system, probably in jessie+1 ?
>>
>>   Q2: Is it OK for packages to depend on a specific init system as
>>   pid 1 ?
>
> [...]
>
>> Firstly, as I have said, TC members should be able to express the
>> preference "only X, X by default but also others, Y by default but
>> also others, Y", which is a perfectly reasonable one but which cannot
>> be expressed by a concurrent ballots
>
> The only reason to interlink these questions is if the ordering of
> someone's preference on the init system question is dependent on their
> preference on these two questions. If that's the case, then whoever
> feels that way should propose a draft which includes an option which
> handles that particular case.
>
>> Secondly, making a decision on the default without clearly stating a
>> requirement for support for multiple systems risks a situation where
>> partisans for the winning system create "facts on the ground" which
>> make it difficult to support multiple systems.
>
> This presupposes bad faith, and even if it were so, such behavior would
> still be possible even if we voted in a single decision.

Even if the TC acts with the purest of motives, there is always a
certain subset of observers likely to assume the worst and ascribe a
bad faith motive.

It is better to head that off by making the TCs intention and thought
process abundantly clear.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MMyNnuYEL-jmZYR=aorq1_0fjwq9wfcrbmkgwwmzzr...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Don Armstrong writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> On Tue, 28 Jan 2014, Ian Jackson wrote:
> > >M. Debian intends to support multiple init systems, for the
> > >   foreseeable future, and so long as their respective communities
> > >   and code remain healthy.  Software outside of an init system's
> > >   implementation may not require a specific init system to be
> > >   pid 1, although degraded operation is tolerable.
> 
> I still don't think the last sentence of this paragraph completely
> handles the cases where someone can legitimately depend on a specific
> init system or specific init system interface.

Would you care to suggest an alternative wording ?

> If we're supporting multiple init systems, then software which doesn't
> support multiple init systems which could feasibly do so is buggy. If
> patches to fix it appear and aren't applied, then people can appeal to
> the CTTE. It's not necessary or feasible for us to anticipate every
> single technical wrinkle and delay making a decision to do so.

I agree with this.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Ian Jackson wrote:
> >M. Debian intends to support multiple init systems, for the
> >   foreseeable future, and so long as their respective communities
> >   and code remain healthy.  Software outside of an init system's
> >   implementation may not require a specific init system to be
> >   pid 1, although degraded operation is tolerable.

I still don't think the last sentence of this paragraph completely
handles the cases where someone can legitimately depend on a specific
init system or specific init system interface.

If we're supporting multiple init systems, then software which doesn't
support multiple init systems which could feasibly do so is buggy. If
patches to fix it appear and aren't applied, then people can appeal to
the CTTE. It's not necessary or feasible for us to anticipate every
single technical wrinkle and delay making a decision to do so.

-- 
Don Armstrong  http://www.donarmstrong.com

Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128141732.gz22...@teltox.donarmstrong.com

Bug#727708: call for votes on default Linux init system for jessie

[Don Armstrong]

On Tue, 28 Jan 2014, Ian Jackson wrote:
>   Q1: Do we intend to support multiple systems long-term, or do we
>   intend to settle on a single system, probably in jessie+1 ?
> 
>   Q2: Is it OK for packages to depend on a specific init system as
>   pid 1 ?

[...]

> Firstly, as I have said, TC members should be able to express the
> preference "only X, X by default but also others, Y by default but
> also others, Y", which is a perfectly reasonable one but which cannot
> be expressed by a concurrent ballots

The only reason to interlink these questions is if the ordering of
someone's preference on the init system question is dependent on their
preference on these two questions. If that's the case, then whoever
feels that way should propose a draft which includes an option which
handles that particular case.
 
> Secondly, making a decision on the default without clearly stating a
> requirement for support for multiple systems risks a situation where
> partisans for the winning system create "facts on the ground" which
> make it difficult to support multiple systems.

This presupposes bad faith, and even if it were so, such behavior would
still be possible even if we voted in a single decision.

-- 
Don Armstrong  http://www.donarmstrong.com

The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140128135107.gy22...@teltox.donarmstrong.com

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Ian Jackson writes ("Re: Bug#727708: call for votes on default Linux init 
system for jessie"):
> > So that leaves my text from yesterday:
> > 
> >M. Debian intends to support multiple init systems, for the
> >   foreseeable future, and so long as their respective communities
> >   and code remain healthy.  Software outside of an init system's
> >   implementation may not require a specific init system to be
> >   pid 1, although degraded operation is tolerable.
> 
> (I forgot to say, I edited that a bit.)

I hope this rephrasing is good enough to satisfy the quibbles which
come up every time about this.  If any of the TC members feel that
there is a better way to put this requirement I would be happy to hear
it.

For the avoidance of doubt, this is to be fleshed out into policy
where the details can be dealt with.

Ian.


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

Bug#727708: call for votes on default Linux init system for jessie

[Ian Jackson]

Ian Jackson writes ("Bug#727708: call for votes on default Linux init system 
for jessie"):
> Bdale Garbee writes ("call for votes on default Linux init system for 
> jessie"):
> >   The default init system for Linux architectures in jessie should be
> > 
> >   D.  systemd
> > 
> >   U.  upstart
> > 
> >   R.  openrc
> > 
> >   V.  sysvinit (no change)
> > 
> >   F.  requires further discussion.

I have lettered these.

> So that leaves my text from yesterday:
> 
>M. Debian intends to support multiple init systems, for the
>   foreseeable future, and so long as their respective communities
>   and code remain healthy.  Software outside of an init system's
>   implementation may not require a specific init system to be
>   pid 1, although degraded operation is tolerable.

(I forgot to say, I edited that a bit.)

> vs something like:
> 
>O. Debian intends to converge on one init system; in jessie+1,
>   packages may require that the default init system is in use.

If we are I to vote now, I would like to see on the ballot at least:
   DM  systemd by default, but also others
   DO  systemd only in jessie+1
   UM  upstart by default, but also others
   UO  upstart only in jessie+1
   RM  openrc by default, but also others
   VM  sysvinit by default, but also others

I don't think RO and VO make much sense.

Does my text for "O" correctly represent the views of those who want
us to converge on a single system ?

Ian.


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