Re-Proposal - preserve freedom of choice of init systems

classic Classic list List threaded Threaded
408 messages Options
1234 ... 21
Reply | Threaded
Open this post in threaded view
|

Re-Proposal - preserve freedom of choice of init systems

Ian Jackson-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I wish to propose the following general resolution, and hereby call
for seconds.  This GR resolution proposal is identical to that
proposed by Matthew Vernon in March:
  https://lists.debian.org/debian-vote/2014/03/msg00000.html
and the substantive text is that which was drafted for the purposes of
the technical committee's vote (where they decided not to pass a
resolution on the subject).

IMO developments since March show that the concerns put forward then
were well-founded.  Following discussions elsewhere including -devel I
have received enough offers of seconds by private email.

As Matthew said, I don't think further lengthy discussion of the
issues is likely to be productive, and therefore hope we can bring
this swiftly to a vote.  This is particularly true given the impact on
the jessie release.

Thanks,
Ian.

** Begin Proposal **

0. Rationale

  Debian has decided (via the technical committee) to change its
  default init system for the next release. The technical committee
  decided not to decide about the question of "coupling" i.e. whether
  other packages in Debian may depend on a particular init system.

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

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

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

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

2. Loose coupling of init systems

  In general, software may not require a specific init system to be
  pid 1.  The exceptions to this are as follows:

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

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

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

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

3. Notes and rubric

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

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

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

** End Proposal **
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUP96EAAoJEOPjOSNItQ05JYcH/367UqEXLQ3BkWdm2nIGeNN2
rAkdFTso+H3qckCIZnltbWuV+2cZmqXAFac627GoT2hvnu4KwrsiKgyu1PInVWPh
0XUt/8eeR95v2B9JYMuOSlxOOPLwgRZLpJ7vtd1pEU+Skrml0hoHFPCqbrFFathz
K92Kv6HFd5v9vgc1nJir719wZ0zZe20ChSRc8wyMCaM68kddnmRJcpyWF7A3o2jD
9M4coOVlBQRt7kAu65LHV72OcjJbWq4qGeTIxBIExk1nWKNLRYEOHveF7nSaiLxk
D4t0466fknL23SYukhpRSjAdcr6/3tHp7pbZGBHQfrszyb1pQvzL1oNGgBUn4dw=
=eHpN
-----END PGP SIGNATURE-----

--


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/21567.57029.724173.958520@...

Reply | Threaded
Open this post in threaded view
|

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

Neil McGovern via nm
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
> I wish to propose the following general resolution, and hereby call
> for seconds.

Your proposal has been received and is signed correctly.

Neil
--

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon Richter-2
In reply to this post by Ian Jackson-2
Hi,

On 16.10.2014 17:05, Ian Jackson wrote:

> I wish to propose the following general resolution, and hereby call
> for seconds.

[...]

> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
>
> ** End Proposal **
>
Seconded.

   Simon


signature.asc (308 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bernhard R. Link-2
In reply to this post by Ian Jackson-2
* Ian Jackson <[hidden email]> [141016 17:05]:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I wish to propose the following general resolution, and hereby call
> for seconds.  This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
>   https://lists.debian.org/debian-vote/2014/03/msg00000.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
>
> IMO developments since March show that the concerns put forward then
> were well-founded.  Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
>
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.
>
> Thanks,
> Ian.
>
> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
>
> ** End Proposal **
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBCAAGBQJUP96EAAoJEOPjOSNItQ05JYcH/367UqEXLQ3BkWdm2nIGeNN2
> rAkdFTso+H3qckCIZnltbWuV+2cZmqXAFac627GoT2hvnu4KwrsiKgyu1PInVWPh
> 0XUt/8eeR95v2B9JYMuOSlxOOPLwgRZLpJ7vtd1pEU+Skrml0hoHFPCqbrFFathz
> K92Kv6HFd5v9vgc1nJir719wZ0zZe20ChSRc8wyMCaM68kddnmRJcpyWF7A3o2jD
> 9M4coOVlBQRt7kAu65LHV72OcjJbWq4qGeTIxBIExk1nWKNLRYEOHveF7nSaiLxk
> D4t0466fknL23SYukhpRSjAdcr6/3tHp7pbZGBHQfrszyb1pQvzL1oNGgBUn4dw=
> =eHpN
> -----END PGP SIGNATURE-----
I hearby seconded this proposal,

        Bernhard R. Link

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alessio Treglia-3
In reply to this post by Ian Jackson-2
Il giorno gio, 16/10/2014 alle 16.05 +0100, Ian Jackson ha scritto:

> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
>
> ** End Proposal **
Seconded.


--
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         |     [hidden email]
Ubuntu Core Developer    |  [hidden email]
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stefano Zacchiroli
In reply to this post by Ian Jackson-2
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.

Speaking of which,
  before deciding anything (including seconding it or not) about this
proposal, I'd like to know what impact a positive outcome of this GR
would have on the work load of teams whose efforts we badly need to put
the Jessie release in shape.

Specifically: have you, or anyone else involved in this GR, asked the
GNOME team and the release team, whether a positive outcome of this GR
is going to disrupt their work (plans) or not?

[ Those teams are just the first two I could think of. Please speak up
  if you are aware of teams that might be heavily impacted, one way or
  another, by the outcome of this GR. ]

I've sympathy for the motives behind this GR, but discovering that those
teams might have their Jessie plans disrupted---on a very short
notice---by this GR will make me think twice or thrice before helping in
making it happen.

Cheers.
--
Stefano Zacchiroli  . . . . . . .  [hidden email] . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Iustin Pop-3
In reply to this post by Ian Jackson-2
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:

> I wish to propose the following general resolution, and hereby call
> for seconds.  This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
>   https://lists.debian.org/debian-vote/2014/03/msg00000.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
>
> IMO developments since March show that the concerns put forward then
> were well-founded.  Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
>
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.
>
> Thanks,
> Ian.
>
> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
>
> ** End Proposal **
Seconded.

iustin

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ritesh Raj Sarraf-4
In reply to this post by Alessio Treglia-3
> ** Begin Proposal **

>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
>
> ** End Proposal **
I second this proposal.

--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Florian Lohoff-2
In reply to this post by Ian Jackson-2
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:

>
> I wish to propose the following general resolution, and hereby call
> for seconds.  This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
>   https://lists.debian.org/debian-vote/2014/03/msg00000.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
>
> IMO developments since March show that the concerns put forward then
> were well-founded.  Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
>
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.
>
> Thanks,
> Ian.
>
> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
Seconded.

--
Florian Lohoff                                                 [hidden email]

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jonas Smedegaard via nm
In reply to this post by Ian Jackson-2
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:

>
> I wish to propose the following general resolution, and hereby call
> for seconds.  This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
>   https://lists.debian.org/debian-vote/2014/03/msg00000.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
>
> IMO developments since March show that the concerns put forward then
> were well-founded.  Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
>
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.
>
> Thanks,
> Ian.
>
> ** Begin Proposal **
>
> 0. Rationale
>
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
>
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
>
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
>
> 1. Exercise of the TC's power to set policy
>
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
>
> 2. Loose coupling of init systems
>
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
>
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
>
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
>
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
>
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
>
> 3. Notes and rubric
>
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
>
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
>
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
Seconded.

 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
In reply to this post by Stefano Zacchiroli
Stefano Zacchiroli writes ("Re: Re-Proposal - preserve freedom of choice of init systems"):
> Specifically: have you, or anyone else involved in this GR, asked the
> GNOME team and the release team, whether a positive outcome of this GR
> is going to disrupt their work (plans) or not?

No, I have not.

I am not aware of any underlying bugs in (say) gnome-without-systemd
that would be RC.  But the sentiment behind this GR is that any such
bugs should be considered indeed RC for the whole project.

> I've sympathy for the motives behind this GR, but discovering that those
> teams might have their Jessie plans disrupted---on a very short
> notice---by this GR will make me think twice or thrice before helping in
> making it happen.

I think that if necessary we might have to delay the release.  That
would be a matter for the release team.  I would be very unhappy if we
ditched the ability of people to choose a different init system simply
to maintain our release schedule.

It is very regrettable that this identical resolution didn't get
enough seconds in March.  At least I can say `I foresaw the neeed for
this'.

Ian.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/21568.2030.594087.481240@...

Reply | Threaded
Open this post in threaded view
|

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

Neil McGovern via nm
In reply to this post by Jonas Smedegaard via nm
On Thu, Oct 16, 2014 at 07:57:06PM +0200, Jonas Smedegaard wrote:
> Seconded.
>

I'm getting a bad signature from you, can you try again, perhaps with a
clearsigned mail?

Thanks,
Neil

--

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Neil McGovern via nm
In reply to this post by Ian Jackson-2

On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
> I wish to propose the following general resolution, and hereby call
> for seconds.

Hi,

This reached the required number of seconds at Thu, 16 Oct 2014 17:42:55
UTC, and thus the relevent minimum discussion period of two weeks has
started.

Neil
--

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-8
In reply to this post by Ian Jackson-2
Ian Jackson <[hidden email]> writes:
> I think that if necessary we might have to delay the release.  That
> would be a matter for the release team.  I would be very unhappy if we
> ditched the ability of people to choose a different init system simply
> to maintain our release schedule.

Hurray, what a great idea to delay everything *now*.

And all because some people believe in conspiracy theories about Red
Hat...

Anyone around for the alternative choice of just one init system? In the
same spirit of just one libc? (Yeah, choice of course does not include
the C library or the kernel if it's just anti-evil-Red-Hat...)

Ansgar


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/8738anyipe.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Adam D. Barratt
In reply to this post by Ian Jackson-2
On Thu, 2014-10-16 at 19:01 +0100, Ian Jackson wrote:

> Stefano Zacchiroli writes ("Re: Re-Proposal - preserve freedom of choice of init systems"):
> > I've sympathy for the motives behind this GR, but discovering that those
> > teams might have their Jessie plans disrupted---on a very short
> > notice---by this GR will make me think twice or thrice before helping in
> > making it happen.
>
> I think that if necessary we might have to delay the release.  That
> would be a matter for the release team.  I would be very unhappy if we
> ditched the ability of people to choose a different init system simply
> to maintain our release schedule.

Speaking for no-one other than myself, I _am_ very unhappy that given
how long the discussion has been rumbling on for, and how much
opportunity there has been, that anyone thought that two weeks before
the freeze (which has had a fixed date for nearly a year now) was the
right time to raise this.

Regards,

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/1413484103.2260.10.camel@...

Reply | Threaded
Open this post in threaded view
|

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

Steve Langasek
In reply to this post by Ansgar Burchardt-8
On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote:
> Ian Jackson <[hidden email]> writes:
> > I think that if necessary we might have to delay the release.  That
> > would be a matter for the release team.  I would be very unhappy if we
> > ditched the ability of people to choose a different init system simply
> > to maintain our release schedule.

> Hurray, what a great idea to delay everything *now*.

> And all because some people believe in conspiracy theories about Red
> Hat...

This response is uncalled for.  The /existence/ of conspiracy nuts is no
reason to insult the members of the Debian community who are unhappy with
the increasingly monolithic approach to system design that is being
advocated in some quarters.

--
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 Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Adam D. Barratt
Hi,

On Donnerstag, 16. Oktober 2014, Adam D. Barratt wrote:
> Speaking for no-one other than myself, I _am_ very unhappy that given
> how long the discussion has been rumbling on for, and how much
> opportunity there has been, that anyone thought that two weeks before
> the freeze (which has had a fixed date for nearly a year now) was the
> right time to raise this.

Exactly.

And for what exactly? Gnome right now is installable with systemd-shim +
sysvinit, why can't this GR wait until after release when the dust has
settled?

This is a GR based on rumors, which is very sad.

And even sadder, what the GR states: "we think this software is not we like it
to be. And/but we force *you* to change it - whether *you* think it's sensible
or not." That's childish, to say at best :(

If you don't like upstreams choices, *you* should write patches. Not GRs
telling other people to do so.


cheers,
        Holger, thinking about how a sensible GR to counter this one could be
                written


signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-8
In reply to this post by Steve Langasek
Steve Langasek <[hidden email]> writes:

> On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote:
>> Hurray, what a great idea to delay everything *now*.
>
>> And all because some people believe in conspiracy theories about Red
>> Hat...
>
> This response is uncalled for.  The /existence/ of conspiracy nuts is no
> reason to insult the members of the Debian community who are unhappy with
> the increasingly monolithic approach to system design that is being
> advocated in some quarters.

Fine, conspiracy theories might be a bit too much. Let's call it
strategic alliances that are a very real threat to Debian that are
mediated by shared employment and might also involve corporate
alliances.

Ansgar
 - still slightly irritated by endless threads on -user@ -


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/87ppdrvog8.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Aigars Mahinovs-2
In reply to this post by Holger Levsen-2
On 16 October 2014 21:41, Holger Levsen <[hidden email]> wrote:
> And for what exactly? Gnome right now is installable with systemd-shim +
> sysvinit, why can't this GR wait until after release when the dust has
> settled?

That is great! And is exactly what the GR is supposed make sure keeps
happening. Debian would simply make a public commitment to keep
supporting use of all Debian-packaged software with any init system.
Does this also mean that such a GR is not actually a blocker for
jessie release?

> If you don't like upstreams choices, *you* should write patches. Not GRs
> telling other people to do so.

We have all kinds of policies about what is fine in a package and what
is a Release Critical bug. That is a big part of what makes a
distribution. This simply adds - "must be able to work with any init
system running at PID 1" to those requirements.

--
Best regards,
    Aigars Mahinovs        mailto:[hidden email]
  #--------------------------------------------------------------#
 | .''`.    Debian GNU/Linux (http://www.debian.org)            |
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv)     |
 | `. `'    Linux Administration and Free Software Consulting   |
 |   `-                                 (http://www.aiteki.com) |
 #--------------------------------------------------------------#


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/CABpYwDUbV0YmV3b63MSizThe9GfN1xkoASGChGVtMcR4nNFAJw@...

Reply | Threaded
Open this post in threaded view
|

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

Adam D. Barratt
On Thu, 2014-10-16 at 22:00 +0300, Aigars Mahinovs wrote:
> We have all kinds of policies about what is fine in a package and what
> is a Release Critical bug. That is a big part of what makes a
> distribution. This simply adds - "must be able to work with any init
> system running at PID 1" to those requirements.

Strictly speaking, "what is a Release Critical bug" is the release
team's purview, as per their delegation. (Of course, subject to being
overriden by the project as with any other delegate.)

Regards,

Adam


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/1413486565.2260.15.camel@...

1234 ... 21