Bug#727708: init system resolution - revised proposal

2014-01-31 Thread Svante Signell 
To CTTE,

In the wait for your decision next week, many of us assume that you take
into consideration the many misleading and false statements that have
been written about about sysvinit + openrc/insserv.

Additionally, consider this, please:
Adopting systemd (and gnome, dbus->kdbus, wayland, etc depending on it)
is very dangerous for the future of Free Software :-(

(I wonder which view FSF would have if they had been involved)

Thanks, have a nice weekend!


-- 
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/1391175670.20080.53.ca...@g3620.my.own.domain

Bug#727708: init system resolution - revised proposal

2014-01-31 Thread Ian Jackson 
Josh Triplett writes ("Bug#727708: init system resolution - revised proposal"):
> How confident are you that the entire technical committee and the
> community of people filing bugs in the future will share your
> interpretation of that statement in the resolution,

I'm confident that the policy maintainers will flesh out the meaning
appropriately.

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/21227.37382.434487.649...@chiark.greenend.org.uk

Bug#727708: init system resolution - revised proposal

2014-01-31 Thread Ian Jackson 
Keith Packard writes ("Re: Bug#727708: init system resolution - revised 
proposal"):
> Ian Jackson  writes:
> > Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
> > ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
> > the vote sooner.
> 
> I can vote with this ballot.

Thanks.

> Sorry I had to disappear in the middle of
> the meeting; that all turned out for naught as the flight I was on got
> canceled, and I'll be home for the weekend after all.

Well, I guess you get a weekend at home as compensation for the
hassle.

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/21227.37283.406219.421...@chiark.greenend.org.uk

Bug#727708: init system resolution - revised proposal

2014-01-31 Thread Ian Jackson 
Josh Triplett writes ("Bug#727708: init system resolution - revised proposal"):
> A couple of comments inline below.
...
> There is an issue with this wording, which I don't think is intended.
> Sometimes, the easiest way to maintain support for multiple init systems
> involves having a family of packages, each of which enables support for
> one init system or family of init systems.  For instance, consider a
> gnome-session-systemd package which uses systemd user sessions, provided
> in parallel with a compatibility package that does not.  Or, consider
> the systemd-shim package.  As written, this clause would prohibit such
> alternative packages, even though *collectively* the packages satisfy
> this requirement.  I would suggest adding language like the following,
> optionally with the following [non-binding] example:

This is why we use the word "software", not "packages".

>Packages which form part of a set of alternatives integrating with
>different init systems need not individually run on other init
>systems, as long as the packages collectively meet the requirements
>of this section.  [ For example, a package using systemd to launch a
>user session, provided as an alternative to a package that runs on
>sysvinit, need not itself run on sysvinit. ]

I agree with the intent here but I think it's best done in policy
rather than in the TC resolution.

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/21227.37234.22617.972...@chiark.greenend.org.uk

Bug#727708: init system resolution - revised proposal

2014-01-31 Thread Josh Triplett 
Don Armstrong wrote:
> On Thu, 30 Jan 2014, Josh Triplett wrote:
> > Ian Jackson wrote:
> > >Software outside of an init system's implementation may not require
> > >a specific init system to be pid 1, although degraded operation is
> > >tolerable.
> >
> > For instance, consider a gnome-session-systemd package which uses
> > systemd user sessions, provided in parallel with a compatibility
> > package that does not. Or, consider the systemd-shim package. As
> > written, this clause would prohibit such alternative packages, even
> > though *collectively* the packages satisfy this requirement.
>
> Using "software" instead of "packages" sidesteps this problem, I think,
> since that avoids the technical details of how such compatibility is
> implemented.

How confident are you that the entire technical committee and the
community of people filing bugs in the future will share your
interpretation of that statement in the resolution, versus the
interpretation that would result in an automatic RC bug on *any* package
that "Depends: systemd-sysv" (or logical equivalent), even if an
alternative package exists?  And to ask the reverse question: given your
interpretation above, how averse are you to making some kind of
clarification along the lines of what you said above official rather
than unofficial?  I'd hate to see people arguing over this ruling later
if a one-sentence clarification could make it completely unambiguous.

- 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/20140131082735.GA30160@leaf

Re: Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Bdale Garbee 
Petr Baudis  writes:

>   Would such a particular example of (greatly, but not fatally) degraded
> operation fall within the intent of this proposal?

I think so, yes.

I do think forcing users who've made a conscious decision to live this
way to click through a warning pop-up on each login is rather unkind,
though.  If some mechanism were provided to mark such a thing as "yes,
I've seen this warning, don't bother me again" until perhaps the next
GNOME version upgrade, that would seem like a much better way to treat
such users.

Bdale


pgphoRFc5cnlQ.pgp
Description: PGP signature

Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Keith Packard 
Ian Jackson  writes:

> Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
> ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
> the vote sooner.

I can vote with this ballot. Sorry I had to disappear in the middle of
the meeting; that all turned out for naught as the flight I was on got
canceled, and I'll be home for the weekend after all.

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


pgpCDqkwKLA2I.pgp
Description: PGP signature

Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Petr Baudis 
  Hi!

  Apologies for jumping into the discussion even though I'm not a Debian
Developer.

> == dependencies rider version L (Loose coupling) ==
> 
>This decision is limited to selecting a default initsystem; we
>continue to welcome contributions of support for all init systems.
> 
>Software outside of an init system's implementation may not require
>a specific init system to be pid 1, although degraded operation is
>tolerable.
> 
>Maintainers are encouraged to accept technically sound patches
>to enable improved interoperation with various init systems.

  I'd just like to clarify - say we have a scenario (that I assume might
be realistic) where without systemd, locking screen in GNOME and some
other fairly basic features do not work (have unfixed bugs, possibly
with security implications; possibly these features would be entirely
disabled because of that).  GNOME would also display a warning window on
login notifying the user that for a proper GNOME experience, they should
switch their system to systemd.  Some *gnome* packages would have
Recommends: systemd.

  (Nevertheless, installing (major components of) GNOME might still
be useful for users that do not wish to use the complete desktop
environment but perhaps would want to install a variety of GNOME
applications or work around these issues in their special-purpose
environment.)

  Would such a particular example of (greatly, but not fatally) degraded
operation fall within the intent of this proposal?

  Thanks,

Petr "Pasky" Baudis


-- 
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/20140131005925.gf19...@machine.or.cz

Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Don Armstrong 
On Thu, 30 Jan 2014, Josh Triplett wrote:
> Ian Jackson wrote:
> >Software outside of an init system's implementation may not require
> >a specific init system to be pid 1, although degraded operation is
> >tolerable.
> 
> For instance, consider a gnome-session-systemd package which uses
> systemd user sessions, provided in parallel with a compatibility
> package that does not. Or, consider the systemd-shim package. As
> written, this clause would prohibit such alternative packages, even
> though *collectively* the packages satisfy this requirement.

Using "software" instead of "packages" sidesteps this problem, I think,
since that avoids the technical details of how such compatibility is
implemented.

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

Have you ever noticed: the most vocal superpatriots are the old men
who send young men out to die.
 -- Harlan Ellison "Basilisk" (_Deathbird Stories_ p73)


-- 
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/20140131002105.gb24...@rzlab.ucr.edu

Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Josh Triplett 
A couple of comments inline below.

Ian Jackson wrote:
> == dependencies rider version T (Tight coupling) ==
> 
>This decision is limited to selecting a default initsystem; we
>continue to welcome contributions of support for all init systems.
> 
>Software may require a specific init system to be pid 1.
> 
>However, where feasible, software should interoperate with
>all 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.
> 
> == dependencies rider version L (Loose coupling) ==
> 
>This decision is limited to selecting a default initsystem; we
>continue to welcome contributions of support for all init systems.
> 
>Software outside of an init system's implementation may not require
>a specific init system to be pid 1, although degraded operation is
>tolerable.

There is an issue with this wording, which I don't think is intended.
Sometimes, the easiest way to maintain support for multiple init systems
involves having a family of packages, each of which enables support for
one init system or family of init systems.  For instance, consider a
gnome-session-systemd package which uses systemd user sessions, provided
in parallel with a compatibility package that does not.  Or, consider
the systemd-shim package.  As written, this clause would prohibit such
alternative packages, even though *collectively* the packages satisfy
this requirement.  I would suggest adding language like the following,
optionally with the following [non-binding] example:

   Packages which form part of a set of alternatives integrating with
   different init systems need not individually run on other init
   systems, as long as the packages collectively meet the requirements
   of this section.  [ For example, a package using systemd to launch a
   user session, provided as an alternative to a package that runs on
   sysvinit, need not itself run on sysvinit. ]

- 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/20140131000141.GA29048@leaf

Bug#727708: init system resolution - revised proposal

2014-01-30 Thread Ian Jackson 
We had a good drafting session on IRC.  Here are the results.
I hereby propose (and propose and do not accept amendments as
necessary), so as to provide the following options:

  DT   systemd default in jessie, requiring specific init is allowed
  DL   systemd default in jessie, requiring specific init NOT allowed

  UT   upstart default in jessie, requiring specific init is allowed 
  UL   upstart default in jessie, requiring specific init NOT allowed

  OT   openrc default in jessie, requiring specific init is allowed
  OL   openrc default in jessie, requiring specific init NOT allowed

  VT   sysvinit default in jessie, requiring specific init is allowed
  VL   sysvinit default in jessie, requiring specific init NOT allowed

  GR   project should decide via GR

  FD   further discussion

Each of these consists of the applicable sections from the resolution
text below (which is in 727708_initsystem/draft-resolution.txt in
git).

We agreed that we would call for votes on Monday night (let's say,
18:00 UTC) unless any TC member objects.  We will start voting sooner
if everyone agrees that this is the good ballot text.

Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
the vote sooner.

Thanks,
Ian.

== version D (systemD) ==

   The default init system for Linux architectures in jessie should
   be systemd.

== version U (Upstart) ==

   The default init system for Linux architectures in jessie should
   be upstart.

== version O (Openrc) ==

   The default init system for Linux architectures in jessie should
   be openrc.

== version V (sysVinit) ==

   The default init system for Linux architectures in jessie should
   be sysvinit (no change).

== version GR (General Resolution) ==

   The Technical Committee requests that the project decide the
   default init system for jessie by means of General Resolution.

== dependencies rider version T (Tight coupling) ==

   This decision is limited to selecting a default initsystem; we
   continue to welcome contributions of support for all init systems.

   Software may require a specific init system to be pid 1.

   However, where feasible, software should interoperate with
   all 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.

== dependencies rider version L (Loose coupling) ==

   This decision is limited to selecting a default initsystem; we
   continue to welcome contributions of support for all init systems.

   Software outside of an init system's implementation may not require
   a specific init system to be pid 1, although degraded operation is
   tolerable.

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

== rider for all versions except GR ==

   This decision is automatically vacated by any contrary General
   Resolution which passes by a simple majority.  In that case the
   General Resolution takes effect and the whole of this TC resolution
   is to be taken as withdrawn by the TC, just as if the TC had
   explicitly withdrawn it by a subsequent TC resolution.

-- 


-- 
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/21226.41292.366504.997...@chiark.greenend.org.uk