date:20141017

Hi,

It is now clear that we will have a vote on this issue. I think that we
should use this opportunity to clarify the Project's position, and that's
not something that would be achieved if Further Discussion were to
win.

I am therefore bringing forward an alternative proposal, deeply inspired
from the Advice: sysvinit compatibility in jessie and multiple init
support option of the TC resolution on init system coupling[1], which
was originally written by Russ Allbery[2] and was then amended by many
participants to the discussion in February 2014.

[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html

- begin proposal -8
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.  However, the technical
committee stated in #746715 that [it] expects maintainers to continue to
support the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason.

The Debian Project states that:

   Software should support as many architectures as reasonably possible,
   and it should normally support the default init system on all
   architectures for which it is built.  There are some exceptional cases
   where lack of support for the default init system may be appropriate,
   such as alternative init system implementations, special-use packages
   such as managers for non-default init systems, and cooperating
   groups of packages intended for use with non-default init systems.
   However, package maintainers should be aware that a requirement for a
   non-default init system will mean the software will be unusable for
   most Debian users and should normally be avoided.

   Package maintainers are strongly encouraged to merge any contributions
   for support of any init system, and to add that support themselves if
   they're willing and capable of doing so.  In particular, package
   maintainers should put a high priority on merging changes to support
   any init system which is the default on one of Debian's non-Linux
   ports.

   For the jessie release, all software that currently supports being run
   under sysvinit should continue to support sysvinit unless there is no
   technically feasible way to do so.  Reasonable changes to preserve
   or improve sysvinit support should be accepted through the jessie
   release.  There may be some loss of functionality under sysvinit if
   that loss is considered acceptable by the package maintainer and
   the package is still basically functional, but Debian's standard
   requirement to support smooth upgrades from wheezy to jessie still
   applies, even when the system is booted with sysvinit.

The Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.


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 above.
-- end proposal --8

Lucas


signature.asc
Description: Digital signature

Reducing the discussion and the voting period to 1 week

Hi,

On 17/10/14 at 08:38 +0100, Matthew Vernon wrote:
 I wonder if, in the circumstances, the DPL should use their power
 under 4.2.4 to reduce the discussion period to 1 week. I'd be
 surprised if anyone is likely to change their view on the desirability
 of choice of init system now - as others have pointed out, the
 arguments have been rumbling on for a time.

I am considering doing that. On the other hand, now that we are going to
vote anyway, I think that we should use this opportunity to clarify the
project's position on this issue, which would not be achieved if FD won.

So, I think that we need alternative proposal(s), and I just put forward
one based on the Advice: sysvinit compatibility in jessie and multiple
init support option of the TC resolution on init system coupling.

But designing and tuning alternative proposals might take time, so I
would prefer to wait a few days before reducing the discussion period,
to ensure that we vote with a sensible ballot. I will decide in the
middle of next week about that.


There's also the possibility to use 4.2.3 to reduce the voting period to
one week. Assuming we would be voting over the last week of october or
the first of november, are there strong reasons not to reduce the voting
period to one week? This is a vacation period in some schools in France
and maybe elsewhere, but that is usually not one where many people are
away and offline.

Lucas


signature.asc
Description: Digital signature

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

2014-10-17 Thread Arto Jantunen

Matthew Vernon matt...@debian.org writes:
 I wonder if, in the circumstances, the DPL should use their power
 under 4.2.4 to reduce the discussion period to 1 week. I'd be
 surprised if anyone is likely to change their view on the desirability
 of choice of init system now - as others have pointed out, the
 arguments have been rumbling on for a time.

The part that worries me about this GR isn't really will systemd win or
lose. I'm somewhat worried about the jessie release being disturbed by
this, and even more worried that we have moved to creating technical
policy by GR without even attempting to use the normal Policy process
first. This GR does not override the TC, but it does unnecessarily
override the Policy process, and also overrides the authority of the
Release Team on deciding what is RC and what isn't.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq7zqfrw@kirika.int.wmdata.fi

Re: Reducing the discussion and the voting period to 1 week

2014-10-17 10:01 GMT+02:00 Lucas Nussbaum lea...@debian.org:
 So, I think that we need alternative proposal(s), [...]

I agree with this point in principle, but we should avoid having too
many options, leading to scattered votes. One party could win with
less than 25% of the votes if the other ones are stealing votes one
another, especially if they're aiming at the same goal, but with
different statements.

I see the Project is divided, and I see this like a Black Or White
decision, so I'd welcome *two* clear, concise, and final statements to
choose about how the Project wants to move forward. We left too many
grey areas in the previous decisions which created too many
interpretations, and these led to where we are now. This should come
to an end.

Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadk7b0mjtxrqgzx5sxvj399-nc_sbrs9gjmoykuzropae35...@mail.gmail.com

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

On Thursday 16 October 2014 11:56 PM, Ansgar Burchardt wrote:
 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...)

I guess we have one libc because it also serves our other ports.

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




signature.asc
Description: OpenPGP digital signature

Re: Reducing the discussion and the voting period to 1 week

On 17/10/14 at 10:28 +0200, Luca Falavigna wrote:
 2014-10-17 10:01 GMT+02:00 Lucas Nussbaum lea...@debian.org:
  So, I think that we need alternative proposal(s), [...]
 
 I agree with this point in principle, but we should avoid having too
 many options, leading to scattered votes. One party could win with
 less than 25% of the votes if the other ones are stealing votes one
 another, especially if they're aiming at the same goal, but with
 different statements.

Note that our voting method is clone-proof, so one proposal cannot steal
votes from one another. That's one of the great things about Condorcet:
you can have similar proposals on the same ballot without causing the
votes to be split. Also numbers like 25% don't really make sense with
Condorcet, unless you limit the calculation to two proposals.
 
Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017084245.ga9...@xanadu.blop.info

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

On Thursday 16 October 2014 11:58 PM, 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.

It was not intentional. Ian asked, and I expressed my opinion.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Andrey Rahmatullin

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
 - begin proposal -8
 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.  However, the technical
 committee stated in #746715 that [it] expects maintainers to continue to
 support the multiple available init systems in Debian.  That includes
 merging reasonable contributions, and not reverting existing support
 without a compelling reason.
 
 The Debian Project states that:
 
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built.  There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
 
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so.  In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
 
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
 
 The Debian Project makes no statement at this time on sysvinit support
 beyond the jessie release.
 
 
 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 above.
 -- end proposal --8
Seconded.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

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

On Friday 17 October 2014 12:11 AM, Holger Levsen 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?

The world isn't just GNOME.

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

Now for me. systemd may be a good linux-only tool. But for Debian, as a
project, for something as fundamental as an  init, sticking to it is not
a wise choice. If the project wants to do that, knock off all the
non-Linux efforts first.

As a base foundation, our choices should be things which are wide enough
to embrace all our sub projects. Why didn't we do the same with
network-manager ?

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature

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

On Friday 17 October 2014 12:30 AM, Aigars Mahinovs wrote:
 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.
Seconded.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Thorsten Glaser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Ian Jackson dixit:

I wish to propose the following general resolution, and hereby call

(d-d-a would have been nice, but this time I found it in time.)

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

bye,
//mirabilos
- -- 
diogenese Beware of ritual lest you forget the meaning behind it.
igli yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)

iQIcBAEBCQAGBQJUQNh+AAoJEHa1NLLpkAfg9x0QAIvGeyKQhtseT3NYo6ySd45h
OqISkbeLQnSmCdpbtVlq6PFEaXlNYFnUiXr1//wOrcZAiDocx5iT+jPjULznLoaL
BSRO/vFLUkbmix5tIyYiI3AymXb5KYR0c8JUAvyTChuFf0feavXt0Ew0zMxANBma
zKTgnC2TJDAwJHu34kE2KwhidQtpKwi8Nyv9FsnMN1e2UvpBnEspgT+y86fS7wxT
X7VWSObqpOupTvHV7LTogTP5e6p4AX7E+MC3TOOUtbWzFNd1eSlVxBuQirhlxg1M
0vxgjeb2PhdMGOLpuFtrJdkEcWXOeDwnOKIDRVg01Q1OPLIuMZz9i7aba0gmkc+/
kMp05cV1/pTDuKMZpRB35qmzWbDqRGBdnsQQn0yoEcL4uoXD8Mv/PwpymRExEwMG
ODNkm4L1vqQ9NbxNxGzd1HjVIlFut+E+Z4uXysLpLmm+DqwfDEscEsCzaEOWykTt
0l4exBgmZTRNLxXA42ctbpFqISQu0oGBBj8R7U4o3NO6UUlE1MEPIEwAurYBiPFi
ykTNARS4rlFwNmAuiIgcBWJMmM96pYgfOMf0SG6Io3uCjkHD2qNnaKqSnDTuChUL
0KKmJQHlOWeYCzZNEuHxk5+2ALTBMlptQhidUXpepg000mBnE+L1ukexbwXYuxQd
0PhxIoMChD2ZDv3YJu8K
=f6kG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1410170847590.12...@herc.mirbsd.org

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

On Friday 17 October 2014 12:43 AM, Ansgar Burchardt wrote:
 Aigars Mahinovs aigar...@debian.org writes:
  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.
 No, it does not mean packages have to work with *any* init system. It's
 specifically aimed against a specific init replacement, see [1].

And for the Debian project, that *specific* init system shouldn't be
systemd, in my opinion, given the breadth of sub projects we have.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Hörmetjan Yiltiz

Users still cannot vote? Or if we can, how?

Best
，

He who is worthy to receive his days and nights is worthy to receive* all
else* from you (and me).
 The Prophet, Gibran Kahlil

Re: Reducing the discussion and the voting period to 1 week

2014-10-17 10:42 GMT+02:00 Lucas Nussbaum lu...@debian.org:
 Note that our voting method is clone-proof, so one proposal cannot steal
 votes from one another. That's one of the great things about Condorcet:
 you can have similar proposals on the same ballot without causing the
 votes to be split. Also numbers like 25% don't really make sense with
 Condorcet, unless you limit the calculation to two proposals.

Yes, I'm fully aware of that.
I still consider a choice between a very few options to be more direct
to everybody, though (fellow developers, our users, and the vocal
minority).

Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADk7b0OuUzTjeWEUPdkO5-22woS-8=tcqnbywbnmh79s+s2...@mail.gmail.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Holger Levsen

Hi,

On Freitag, 17. Oktober 2014, Lucas Nussbaum wrote:
 I am therefore bringing forward an alternative proposal, deeply inspired
 from the Advice: sysvinit compatibility in jessie and multiple init
 support option of the TC resolution on init system coupling[1], which
 was originally written by Russ Allbery[2] and was then amended by many
 participants to the discussion in February 2014.
 
 [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
 [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
 
 - begin proposal -8
 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.  However, the technical
 committee stated in #746715 that [it] expects maintainers to continue to
 support the multiple available init systems in Debian.  That includes
 merging reasonable contributions, and not reverting existing support
 without a compelling reason.
 
 The Debian Project states that:
 
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built.  There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
 
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so.  In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
 
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
 
 The Debian Project makes no statement at this time on sysvinit support
 beyond the jessie release.
 
 
 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 above.
 -- end proposal --8

seconded.

Thanks, Lucas.


cheers,
Holger


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

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

2014-10-17 Thread Jonathan Wiltshire


On 2014-10-17 09:35, Hörmetjan Yiltiz wrote:

Users still cannot vote?


No.

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

directhex i have six years of solaris sysadmin experience, from
8-10. i am well qualified to say it is made from bonghits
layered on top of bonghits


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/7d8ca7e368fc1ceaead88828a77b4...@hogwarts.powdarrmonkey.net

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

2014-10-17 Thread Jonathan Dowland

On Fri, Oct 17, 2014 at 08:38:25AM +0100, Matthew Vernon wrote:
 I wonder if, in the circumstances, the DPL should use their power
 under 4.2.4 to reduce the discussion period to 1 week.

I think this is a terrible idea. I agree that there are entrenched people on
two sides of the argument, but there are others (myself included) who want to
give a well-constructed GR (thus, we need a round of amendments to consider)
proper, thorough consideration.

If we start messing with the GR process in this way then whoever is on the
losing side of the outcome will call the whole process foul.

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017090800.ga3...@chew.redmars.org

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

2014-10-17 Thread Alessio Treglia

On Thu, Oct 16, 2014 at 8:14 PM, Jonas Smedegaard d...@jones.dk wrote:
 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.

 I don't care if monolithic system designs are caused by corporate
 alliances or not.

And me neither.

On Thu, Oct 16, 2014 at 4:05 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

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

I suspect that if the project members could have originally had the
opportunity to vote on *which* init system should be the default on
Jessie well, then it could have been handled much better.

Cheers.

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camhuwowxc5puy0h2pocdhddmmbuak0um252yilfmmbmfvrf...@mail.gmail.com

[RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

Dears,

I'd like to draft an alternative proposal to the GR.
Would anybody consider it a nice addition to the proposals we
currently have, and eventually second it if I asked for it?

Of course, improvements to the text are much more than welcome!

** Begin Alternative Proposal **

Proposal: Reaffirm upstream and maintainers technical competence over
the software they maintain

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 reaffirms the Debian Social Contract #4, in such a way
that Debian acknowledges the choices made by both the Software
Developers (also known as Upstream Developers) and the Debian
Package Maintainers to provide the best Free Software to our Users.

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. Freedom of upstream discrection

Upstream Developers considering a specific Free Software (including,
but not limited to, a particular init system executed as PID 1)
fundamental to deliver the best Software releases, are fully entitled
to require, link, or depend on that Software, or portions of it.

3. Reaffirm Debian Maintainers goodwill

Debian Maintainers' work is aiming to respect the Debian Social
Contract, in such a way to provide our Users the best Free Software
available.

4. Modifications to Upstream Software

Debian Maintainers are fully entitled to provide modifications to
the Free Software they maintain as per DFSG #3, if they judge this
necessary to provide the best software releases. On the other hand,
Debian Maintainers are fully entitled to adhere to Upstream's
decisions to require, link, or depend on a specific Free Software
(including, but no limited to, a particular init system executed as
PID 1), if they consider it necessary to prevent delivering broken,
buggy, or otherwise incomplete software packages.

5. Evidence of defects (bugs)

We strongly reaffirm Debian Maintainers are not deliberately hiding
problems (Social Contract #3). No technical decisions shall be
overruled if no proper evidence of defects, issued in the Debian Bug
Tracking system, is found. Fear, uncertainty, and doubt are not
considered as evidence of defects.

** End Proposal **

Cheers,
Luca

--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CADk7b0Pow2RnOo0A1PK8i8CGAO3KyvF3iDkUDje=n52bzdl...@mail.gmail.com

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Thorsten Glaser

Luca Falavigna dktrkranz at debian.org writes:

 2. Freedom of upstream discrection
 
   Upstream Developers considering a specific Free Software (including,
   but not limited to, a particular init system executed as PID 1)
   fundamental to deliver the best Software releases, are fully entitled
   to require, link, or depend on that Software, or portions of it.

Note that this paragraph *directly* goes against the *definition* of
a software distribution (take upstream software and integrate it with
the whole, occasionally going against upstream’s will) and towards a
unified userland.exe…

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20141017t111637...@post.gmane.org

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Holger Levsen

Hi Luca,

On Freitag, 17. Oktober 2014, Luca Falavigna wrote:
 I'd like to draft an alternative proposal to the GR.
 Would anybody consider it a nice addition to the proposals we
 currently have, and eventually second it if I asked for it?

yes, I would. This proposal looks great! Many thanks!
 
:)


cheers,
Holger, still hoping this will not become even more distractful than
it already is...


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

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

aigar...@debian.org wrote:

To be frank, in cases like logind I would expect the logind binary
package to be split out and its source patched in such a way to allow
it to work without systemd running (however badly) and moving the main
systemd package from Dependencies to Recommended.
It is quite clear that the real world does not and will not meet your
expectations, because logind is not released this way and is not
packaged this way.
Now what?

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m1qmm3$l72$1...@posted-at.bofh.it

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Vincent Cheng

Hi,

On 17/10/14 12:44 AM, Lucas Nussbaum wrote:
 Hi,
 
 It is now clear that we will have a vote on this issue. I think that we
 should use this opportunity to clarify the Project's position, and that's
 not something that would be achieved if Further Discussion were to
 win.
 
 I am therefore bringing forward an alternative proposal, deeply inspired
 from the Advice: sysvinit compatibility in jessie and multiple init
 support option of the TC resolution on init system coupling[1], which
 was originally written by Russ Allbery[2] and was then amended by many
 participants to the discussion in February 2014.
 
 [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
 [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
 
 - begin proposal -8
 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.  However, the technical
 committee stated in #746715 that [it] expects maintainers to continue to
 support the multiple available init systems in Debian.  That includes
 merging reasonable contributions, and not reverting existing support
 without a compelling reason.
 
 The Debian Project states that:
 
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built.  There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
 
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so.  In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
 
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
 
 The Debian Project makes no statement at this time on sysvinit support
 beyond the jessie release.
 
 
 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 above.
 -- end proposal --8

Seconded.

Thanks for writing a counter-proposal Lucas!

Regards,
Vincent



signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Florian Lohoff

Hi Ansgar,

On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk 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...

Nope - My feeling is that we are rushing systemd as fast as possible pushed
for example by the Gnome ecosystem and every warning voice is beeing shut
by we need feature X because Y. We/I have lived with the inadequate init 
system
for 30 years so why are some people pushing _so hard_ to replace it NOW and by 
something
as controversal as the systemd stuff.

The arguments to replace the init system were dishonest (We need dependency 
booting
because booting is slow) in the beginning, and the arguments got replaced with 
complete
different feature argumentation now.

And controversy with systemd even grew more over time since the TCs decision 
because
of the amount of other software projects or functionality systemd maintainers 
decided
to swallow - its not an init system anymore.

Now - after a comparable short time we are already in the position that 
degradation
of the OSes capabilities when not using systemd is beeing acceptable to the 
some/most/all?
of our developers.

Is this acceptable to our users? The major systemd proponents dont care. Debian 
as
an institution should care:

We will be guided by the needs of our users and the free software 
community.

We already got to the point of no return with systemd - and THIS is something
i guess is not something our users asked for, and something the TC did not 
foresee.

If not now - when do people think we can stop and hopefully revert this trend? 

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

Seconded.

On Oct 17, Lucas Nussbaum lu...@debian.org wrote:

It is now clear that we will have a vote on this issue. I think that we
should use this opportunity to clarify the Project's position, and that's
not something that would be achieved if Further Discussion were to
win.

I am therefore bringing forward an alternative proposal, deeply inspired
from the Advice: sysvinit compatibility in jessie and multiple init
support option of the TC resolution on init system coupling[1], which
was originally written by Russ Allbery[2] and was then amended by many
participants to the discussion in February 2014.

[1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
[2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html

- begin proposal -8
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.  However, the technical
committee stated in #746715 that [it] expects maintainers to continue to
support the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason.

The Debian Project states that:

   Software should support as many architectures as reasonably possible,
   and it should normally support the default init system on all
   architectures for which it is built.  There are some exceptional cases
   where lack of support for the default init system may be appropriate,
   such as alternative init system implementations, special-use packages
   such as managers for non-default init systems, and cooperating
   groups of packages intended for use with non-default init systems.
   However, package maintainers should be aware that a requirement for a
   non-default init system will mean the software will be unusable for
   most Debian users and should normally be avoided.

   Package maintainers are strongly encouraged to merge any contributions
   for support of any init system, and to add that support themselves if
   they're willing and capable of doing so.  In particular, package
   maintainers should put a high priority on merging changes to support
   any init system which is the default on one of Debian's non-Linux
   ports.

   For the jessie release, all software that currently supports being run
   under sysvinit should continue to support sysvinit unless there is no
   technically feasible way to do so.  Reasonable changes to preserve
   or improve sysvinit support should be accepted through the jessie
   release.  There may be some loss of functionality under sysvinit if
   that loss is considered acceptable by the package maintainer and
   the package is still basically functional, but Debian's standard
   requirement to support smooth upgrades from wheezy to jessie still
   applies, even when the system is booted with sysvinit.

The Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.


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 above.
-- end proposal --8

Lucas

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Holger Levsen

Hi,

On Freitag, 17. Oktober 2014, Thorsten Glaser wrote:
 Note that this paragraph *directly* goes against the *definition* of
 a software distribution (take upstream software and integrate it with
 the whole, occasionally going against upstream’s will) and towards a
 unified userland.exe…

wait, what? Depending on apache features or postgresql is against the law? We 
all have to use mysql+httpd now??? Also, really, nobody should depend on linux 
features.

this discussion is so much http://ptrace.fefe.de/fpalm30c3.jpg indeed.


cheers,
Holger




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

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 11:17 GMT+02:00 Thorsten Glaser t...@mirbsd.org:
 Note that this paragraph *directly* goes against the *definition* of
 a software distribution (take upstream software and integrate it with
 the whole, occasionally going against upstream’s will) and towards a
 unified userland.exe…

Upstream could or could not consider downstream requirements while
designing its own piece of software, and this is perfectly OK.
As you said, it's the role of the software distribution developers to
adapt a specific to the policy of the distribution, as I affirm in
point 3.

Cheers,
Luca


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADk7b0Put2ioisYuOsLb0-=x2-k-qlag9hppchanaaqaj9r...@mail.gmail.com

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

2014-10-17 Thread Adam D. Barratt


On 2014-10-17 9:45, Ritesh Raj Sarraf wrote:

On Thursday 16 October 2014 11:58 PM, 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.


It was not intentional. Ian asked, and I expressed my opinion.


That doesn't really disagree with my point. Ian could have asked weeks - 
in fact _months_ - ago.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/5042cd3d170a9cc1e19b9003700b4...@mail.adsl.funky-badger.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Michael Banck

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.

I believe currently needs to be clarified - are you talking about the
current state of jessie, of wheezy, or something else?


Michael


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141017093813.ga13...@raptor.chemicalconnection.dyndns.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

Seconded.

 - begin proposal -8
 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.  However, the technical
 committee stated in #746715 that [it] expects maintainers to continue to
 support the multiple available init systems in Debian.  That includes
 merging reasonable contributions, and not reverting existing support
 without a compelling reason.
 
 The Debian Project states that:
 
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built.  There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
 
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so.  In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
 
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
 
 The Debian Project makes no statement at this time on sysvinit support
 beyond the jessie release.
 
 
 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 above.
 -- end proposal --8

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

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

f...@zz.de wrote:

for 30 years so why are some people pushing _so hard_ to replace it NOW and by 
something
as controversal as the systemd stuff.
A vocal minority and a lot of trolls do not make something
controversial.

Considering how widely it has been adopted by other distributions I
would say that for such a big change it is not controversial at all.

We already got to the point of no return with systemd - and THIS is something
i guess is not something our users asked for, and something the TC did not 
foresee.
If I'd asked people what they wanted, they would have asked for a
better horse.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m1qoso$ppa$1...@posted-at.bofh.it

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

Adam D. Barratt writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 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.

I'm very unhappy about that too.  The right time to raise this was in
March when Matthew proposed it and I seconded it.

But that doesn't mean that it isn't still important now.

Ian.


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

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

Adam D. Barratt writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 That doesn't really disagree with my point. Ian could have asked weeks - 
 in fact _months_ - ago.

I did, in March.

Ian.


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

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

2014-10-17 Thread Florian Lohoff

On Fri, Oct 17, 2014 at 09:52:26AM +, Marco d'Itri wrote:
 f...@zz.de wrote:
 
 for 30 years so why are some people pushing _so hard_ to replace it NOW and 
 by something
 as controversal as the systemd stuff.

 A vocal minority and a lot of trolls do not make something
 controversial.

I havent found the mentioned minority you speak about?

 Considering how widely it has been adopted by other distributions I
 would say that for such a big change it is not controversial at all.

Because of pressure of other upstreams going forward everyone adopted it
and this makes it non controversial - i dont get it?!?

 We already got to the point of no return with systemd - and THIS is 
 something
 i guess is not something our users asked for, and something the TC did not 
 foresee.
 If I'd asked people what they wanted, they would have asked for a
 better horse.

And even then the invention of the car was controversial and its even 100 years 
now.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

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

Hi,

Kurt Roeckx:
 Can I ask people to move discussion that is not relevant to the
 vote to some other place?
 
Please don't.

Personally, I do not want -devel to get swamped with yet another discussion 
about this.
Or -release, for that matter.

If it passes (which I consider to be sufficiently unlikely to wonder why
the *censored* Ian even bothered, but whatever), _then_ these lists are the
right places to discuss the implications. Until then, let's keep it here.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Proposed amendement: be more careful when proposing a GR.

Hi,

Charles Plessy:
 ---
 The Debian project asks its members to be more considerate when proposing
 General Resolutions, and in particular to take care that the proposed GR has
 actual chances to be accepted, considering that GRs is a disruptive process
 regardless the outcome of the vote.
 ---
 
Slightly reworded:


The Debian project asks its members to be considerate when proposing
General Resolutions, as the GR process may be disruptive regardless
of the outcome of the vote.

In particular, a proposed GR should have an actual chance of being accepted.


This should probably be part of (the rationale for?) our constitution.
It's not part of the current GR, despite being motivated by it.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Philipp Kern

On Fri, Oct 17, 2014 at 11:14:22AM +0200, Luca Falavigna wrote:
 I'd like to draft an alternative proposal to the GR.
 Would anybody consider it a nice addition to the proposals we
 currently have, and eventually second it if I asked for it?

I'd second this.

Thanks!
Philipp Kern


signature.asc
Description: Digital signature

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

2014-10-17 Thread Aigars Mahinovs

On 17 October 2014 13:27, Matthias Urlichs matth...@urlichs.de wrote:
 If it passes (which I consider to be sufficiently unlikely to wonder why
 the *censored* Ian even bothered, but whatever), _then_ these lists are the
 right places to discuss the implications. Until then, let's keep it here.

From the discussion so far (and please correct me if I am wrong) the
only implication of this passing would be that a failure of
init-system-neutrality would now be a serious bug.

It appears that with systemd-shim this bug is now fixed for Gnome (any
other packages depending on libpam-systemd to get logind
functionality). So this should not be a blocker for jessie release.

I am not aware of any other issues that could impact this release
stemming from this.
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.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 debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDXgCUNjay8=r=drdq6xkzhln-pwh8_c2y8anrrffye...@mail.gmail.com

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

On Oct 17, Florian Lohoff f...@zz.de wrote:

  A vocal minority and a lot of trolls do not make something
  controversial.
 I havent found the mentioned minority you speak about?
Probably because you appear to be in the middle of it...

  Considering how widely it has been adopted by other distributions I
  would say that for such a big change it is not controversial at all.
 Because of pressure of other upstreams going forward everyone adopted it
 and this makes it non controversial - i dont get it?!?
If you postulate some conspiracy to make everybody use systemd then I do 
not think that there is much more that we can argue about.
But even then, if this alleged pressure has been strong enough to make 
every non-kooky distribution adopt systemd then it should be obvious 
that resisting it would be futile for us as well.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 17/10/14 at 11:38 +0200, Michael Banck wrote:
 On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
 For the jessie release, all software that currently supports being run
 under sysvinit should continue to support sysvinit unless there is no
 technically feasible way to do so.
 
 I believe currently needs to be clarified - are you talking about the
 current state of jessie, of wheezy, or something else?

I tried to keep changes from the original text (as voted on by the TC)
to the bare minimum.
But, since the intend here is to allow swift upgrades between stable
releases, it should read:

  For the jessie release, all software available in Debian 'wheezy' that
  supports being run under sysvinit should continue to support sysvinit
  unless there is no technically feasible way to do so.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017110531.ga11...@xanadu.blop.info

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

2014-10-17 Thread Matthew Vernon

Jonathan Dowland j...@debian.org writes:

 On Fri, Oct 17, 2014 at 08:38:25AM +0100, Matthew Vernon wrote:
  I wonder if, in the circumstances, the DPL should use their power
  under 4.2.4 to reduce the discussion period to 1 week.
 
 I think this is a terrible idea. I agree that there are entrenched people on
 two sides of the argument, but there are others (myself included) who want to
 give a well-constructed GR (thus, we need a round of amendments to consider)
 proper, thorough consideration.
 
 If we start messing with the GR process in this way then whoever is on the
 losing side of the outcome will call the whole process foul.

Good point.

Regards,

Matthew

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


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

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Iain Lane

Hi,

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
 […]
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.

The first sentence seems strong to me. There's (almost) always going to
be a technically feasible way to achieve this, given a large enough
changeset. Reasonable changes is right. I suggest replacing the quoted
section with something like

  For the jessie release, maintainers should not remove support for
  running under sysvinit from software which already possesses this
  support, unless it would be unreasonably difficult to preserve in the
  face of other changes the maintainer reasonably desires for jessie.
  Reasonable contributions to re-add or improve sysvinit support should
  be accepted through the jessie release.

Also, what does currently (already in my text) mean? In stable or
testing?

Cheers,

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


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Iain Lane

On Fri, Oct 17, 2014 at 12:00:03PM +0100, Iain Lane wrote:
 Also, what does currently (already in my text) mean? In stable or
 testing?

Okay, I see 20141017110531.ga11...@xanadu.blop.info now.

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


signature.asc
Description: Digital signature

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

2014-10-17 Thread Stefano Zacchiroli

On Fri, Oct 17, 2014 at 11:13:56AM +0100, Ian Jackson wrote:
 I'm very unhappy about that too.  The right time to raise this was in
 March when Matthew proposed it and I seconded it.
 
 But that doesn't mean that it isn't still important now.

Sure. But the drawbacks of having it now are much more severe.

Of the teams I've mentioned in [1], I've already read in this thread
opinions from [individual members of] the release team. And they don't
seem pleased by having this GR at this point. Even though that's just
guess work for now, I suspect other concerned teams will be even *less*
pleased.

[1]: https://lists.debian.org/debian-vote/2014/10/msg5.html

As I've already told you in private mail, I value much more respecting
the work (plans) of teams that have a proven record of putting a stellar
amount of work in getting Debian releases together, than the technical
ability of switching init system --- which, AFAIU, is not even currently
undermined in Jessie.  Such a position of mine is not merely grounded in
abstract principles, it is eminently pragmatic: in a volunteer project
performing technical changes is generally easier than refurbishing
overworked and frustrated teams (that is so assuming you have enough
people power, but high-profile vote-based conflicts are hardly a way to
attract volunteers to a technical project).

For these reasons, and no matter what went wrong in the past with
previous attempts at this GR, I think you should have at the very least
included an applies only to jessie + 1 provision in your proposal.
Doing so would have disentangled this matter from the upcoming freeze,
which, per se, is a well-known cause of stress for the project.

The more I think of it, the more I get convinced that the collateral
damages of this GR will outweigh any of its potential benefits.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . 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
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 17/10/14 at 12:00 +0100, Iain Lane wrote:
 Hi,
 
 On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
  […]
 For the jessie release, all software that currently supports being run
 under sysvinit should continue to support sysvinit unless there is no
 technically feasible way to do so.  Reasonable changes to preserve
 or improve sysvinit support should be accepted through the jessie
 release.
 
 The first sentence seems strong to me. There's (almost) always going to
 be a technically feasible way to achieve this, given a large enough
 changeset. Reasonable changes is right. I suggest replacing the quoted
 section with something like
 
   For the jessie release, maintainers should not remove support for
   running under sysvinit from software which already possesses this
   support, unless it would be unreasonably difficult to preserve in the
   face of other changes the maintainer reasonably desires for jessie.
   Reasonable contributions to re-add or improve sysvinit support should
   be accepted through the jessie release.

I would agree in principle.

However, we are freezing in two weeks, and the current status is that
(AFAIK) all software that supported sysvinit in wheezy continues to
support sysvinit in jessie (thanks to systemd-shim).

So this is a strong requirement, but one that is already met in practice
in the archive, and the current status is unlikely to change by the time
we release. So I don't really see a point in lightening that
requirement.

Lucas


signature.asc
Description: Digital signature

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

2014-10-17 Thread Olav Vitters

On Fri, Oct 17, 2014 at 09:16:49AM +0300, Aigars Mahinovs wrote:
 Actually that is a *very* similar issue. Apps should be
 window-manager-neutral as much as they should be init-system-neutral.
 Imagine if suddenly all Gnome apps stopped working unless you were
 running Metacity. It should not be up to window managers to implement
 all the features that all apps use, it should be up to apps to only
 depend on the common subset of features and to properly handle
 situations when such features are not available.

Turning every bug into a blocker bug severity is a good way ensure it
will become buggy.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017113454.ga5...@bkor.dhs.org

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

2014-10-17 Thread Olav Vitters

On Fri, Oct 17, 2014 at 12:23:15PM +0200, Florian Lohoff wrote:
 Because of pressure of other upstreams going forward everyone adopted it
 and this makes it non controversial - i dont get it?!?

The adaption in openSUSE and Mageia was not due to this. The discussion
is public. If you claim above then provide references.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017114513.gc5...@bkor.dhs.org

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

2014-10-17 Thread Adam D. Barratt


On 2014-10-17 12:00, Aigars Mahinovs wrote:

On 17 October 2014 13:27, Matthias Urlichs matth...@urlichs.de wrote:
If it passes (which I consider to be sufficiently unlikely to wonder 
why
the *censored* Ian even bothered, but whatever), _then_ these lists 
are the
right places to discuss the implications. Until then, let's keep it 
here.



From the discussion so far (and please correct me if I am wrong) the

only implication of this passing would be that a failure of
init-system-neutrality would now be a serious bug.


Note (and this is not splitting hairs) that serious bug is not a 
direct analogue for release-critical bug.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cd3d6102a0b50499dc9017549f59d...@mail.adsl.funky-badger.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Neil McGovern

On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
 I am therefore bringing forward an alternative proposal

Recieved, and verified. Note, this has been proposed by the current
Project Leader, and thus does not require seconds, but will record those
seconding anyway.

Neil
-- 


signature.asc
Description: Digital signature

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

On Friday 17 October 2014 05:10 PM, Olav Vitters wrote:
  The world isn't just GNOME.
 The issue is bigger than just GNOME. Think of e.g. UPower. There is
 various other software which is affected by this. Requiring people to do
 your bidding is against the Debian social contract. While this is pretty
 much what the GR is about. Seems unrealistic, plus seems you're voting
 on something without knowing any specific (just GNOME). If you expect
 upstream/Debian packager teams to take people who cannot bother to
 inform themselves on their topic serious, then geez... good luck but
 you're heading towards a wall.

Not just UPower. UDisks, PolicyKit and many more. And if we don't take a
sensible stand, soon hostname, cron, dns, network, power etc.


In Debian, until the decision in Feb, everything worked with sysvinit.
And then eventually it broke. As we speak today, Udisk + Upower + PolKit
(experimental) does work again.

Buy my point is, things used to work neutrally. Why can't we strive to
do that?

Have the systemd support. I don't think anyone is opposing that. But
don't bring that at the cost of an alternate neutral option.

Why is SysV Init so unacceptable ? It is a neutral init that serves well
for all our sub-projects. Let that be the default choice.

 

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Aigars Mahinovs

On 17 October 2014 15:53, Ritesh Raj Sarraf r...@researchut.com wrote:
 Why is SysV Init so unacceptable ? It is a neutral init that serves well
 for all our sub-projects. Let that be the default choice.

Please do not conflate two very different issues. The default choice
has been decided and is not in question at this point. This is about
ensuring that SysV init (among others) is and continues to be a
*possible* choice for a user.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.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 debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDWoejUKybVpJk=qzz1j1d6hozk20g-mrmvfh5gg4bv...@mail.gmail.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Neil McGovern

On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
 On 17/10/14 at 11:38 +0200, Michael Banck wrote:
  On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
  For the jessie release, all software that currently supports being run
  under sysvinit should continue to support sysvinit unless there is no
  technically feasible way to do so.
  
  I believe currently needs to be clarified - are you talking about the
  current state of jessie, of wheezy, or something else?
 
 I tried to keep changes from the original text (as voted on by the TC)
 to the bare minimum.
 But, since the intend here is to allow swift upgrades between stable
 releases, it should read:
 
   For the jessie release, all software available in Debian 'wheezy' that
   supports being run under sysvinit should continue to support sysvinit
   unless there is no technically feasible way to do so.
 

Hi Lucas,

For clarity, are you formally amending your own text here?

Neil
-- 


signature.asc
Description: Digital signature

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

2014-10-17 Thread Stefano Zacchiroli

On Fri, Oct 17, 2014 at 06:23:30PM +0530, Ritesh Raj Sarraf wrote:
 Why is SysV Init so unacceptable ? It is a neutral init that serves well
 for all our sub-projects. Let that be the default choice.

Ritesh,
  from various mails of yours I got the impression that you are arguing
for changing (back) the default init system. This GR is not about that;
please don't make yet another _thread_ about that either :-)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . 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
Description: Digital signature

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

On Friday 17 October 2014 06:27 PM, Aigars Mahinovs wrote:
 On 17 October 2014 15:53, Ritesh Raj Sarraf r...@researchut.com wrote:
  Why is SysV Init so unacceptable ? It is a neutral init that serves well
  for all our sub-projects. Let that be the default choice.
 Please do not conflate two very different issues. The default choice
 has been decided and is not in question at this point. This is about
 ensuring that SysV init (among others) is and continues to be a
 *possible* choice for a user.

It would be nice to know what possible is defined as.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.



signature.asc
Description: OpenPGP digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
 On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
  On 17/10/14 at 11:38 +0200, Michael Banck wrote:
   On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
   For the jessie release, all software that currently supports being 
run
   under sysvinit should continue to support sysvinit unless there is no
   technically feasible way to do so.
   
   I believe currently needs to be clarified - are you talking about the
   current state of jessie, of wheezy, or something else?
  
  I tried to keep changes from the original text (as voted on by the TC)
  to the bare minimum.
  But, since the intend here is to allow swift upgrades between stable
  releases, it should read:
  
For the jessie release, all software available in Debian 'wheezy' that
supports being run under sysvinit should continue to support sysvinit
unless there is no technically feasible way to do so.
  
 
 Hi Lucas,
 
 For clarity, are you formally amending your own text here?

Yes.

I am expecting other fine-tunings during the next hours/days, so I
initially wanted to gather those changes in a single amended version.
But now that you asked the question, yes, please amend the proposal with
the above change.

Thanks,

Lucas


signature.asc
Description: Digital signature

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

2014-10-17 Thread Olav Vitters

On Fri, Oct 17, 2014 at 06:23:30PM +0530, Ritesh Raj Sarraf wrote:
 On Friday 17 October 2014 05:10 PM, Olav Vitters wrote:
   The world isn't just GNOME.
  The issue is bigger than just GNOME. Think of e.g. UPower. There is
  various other software which is affected by this. Requiring people to do
  your bidding is against the Debian social contract. While this is pretty
  much what the GR is about. Seems unrealistic, plus seems you're voting
  on something without knowing any specific (just GNOME). If you expect
  upstream/Debian packager teams to take people who cannot bother to
  inform themselves on their topic serious, then geez... good luck but
  you're heading towards a wall.
 
 Not just UPower. UDisks, PolicyKit and many more. And if we don't take a
 sensible stand, soon hostname, cron, dns, network, power etc.
 
 
 In Debian, until the decision in Feb, everything worked with sysvinit.
 And then eventually it broke. As we speak today, Udisk + Upower + PolKit
 (experimental) does work again.

That's not a result of Debian going for systemd. It is a result of
upstream decisions. If you're maintaining something and part of the
functionality is provided by systemd, then it is up to the maintainer to
decide.

 Buy my point is, things used to work neutrally. Why can't we strive to
 do that?

Because you're requesting the same functionality to be duplicated.

You're also confusing things. The GR is within Debian, while in your
email you're talking about upstream decisions/changes.

 Have the systemd support. I don't think anyone is opposing that. But
 don't bring that at the cost of an alternate neutral option.

So who will maintain that code?

 Why is SysV Init so unacceptable ? It is a neutral init that serves well
 for all our sub-projects. Let that be the default choice.

I'm not about other init systems. I'm after forcing people to do your
bidding. If some work has to be done, go ahead and do it. Alternative
logind? Cool! But the systemd-shim is a fork, seems to rely on cgmanager
(think nogo on non-Linux), etc.

If you want to force changes at upstream, go ahead. This is a GR within
Debian. So as an upstream I'd expect Debian to do the work as well as
the ongoing maintenance to make it happen.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017131441.gd5...@bkor.dhs.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Dimitri John Ledkov

On 17 October 2014 13:44, Neil McGovern ne...@debian.org wrote:
 On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
 I am therefore bringing forward an alternative proposal

 Recieved, and verified. Note, this has been proposed by the current
 Project Leader, and thus does not require seconds, but will record those
 seconding anyway.

Phf, did not know that =) probably something that ought to be fixed as well as
the TC super-majority bug. And thus to pre-empt pointless votes of no
confidence,
if DPL can't even get enough seconds (which I'm sure will not be the
case with this
proposal)

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluibnqcczommvn_pawu-h81os4yfasa_gngz7vnndny...@mail.gmail.com

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Neil McGovern

On Fri, Oct 17, 2014 at 03:25:03PM +0200, Lucas Nussbaum wrote:
 On 17/10/14 at 13:59 +0100, Neil McGovern wrote:
  On Fri, Oct 17, 2014 at 01:05:31PM +0200, Lucas Nussbaum wrote:
   On 17/10/14 at 11:38 +0200, Michael Banck wrote:
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
For the jessie release, all software that currently supports being 
 run
under sysvinit should continue to support sysvinit unless there is 
 no
technically feasible way to do so.

I believe currently needs to be clarified - are you talking about the
current state of jessie, of wheezy, or something else?
   
   I tried to keep changes from the original text (as voted on by the TC)
   to the bare minimum.
   But, since the intend here is to allow swift upgrades between stable
   releases, it should read:
   
 For the jessie release, all software available in Debian 'wheezy' that
 supports being run under sysvinit should continue to support sysvinit
 unless there is no technically feasible way to do so.
   
  
  Hi Lucas,
  
  For clarity, are you formally amending your own text here?
 
 Yes.
 
 I am expecting other fine-tunings during the next hours/days, so I
 initially wanted to gather those changes in a single amended version.
 But now that you asked the question, yes, please amend the proposal with
 the above change.
 

Thanks, updated. I want to get the web pages etc updated asap, and post
to DDA. I look forward to any more changes :)

Neil
-- 


signature.asc
Description: Digital signature

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

2014-10-17 Thread Miguel Landaeta

On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
 -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/msg0.html

IMO, it's not the time to propose such GR again. #kthxbye.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
Faith means not wanting to know what is true. -- Nietzsche


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

Hi,

Lucas Nussbaum:
 For example, Ian's software may not require a specific init system to be pid
 1 could be abused by introducing a systemd-clone package in the archive

Please try to ignore maleficial intent and similar failure modes.

If we'd go that way, not only would we need to define (and capitalize)
every second word, but the GR proposals would be a lot longer – and
correspondingly harder to understand / apply correctly.

-- 
-- Matthias Urlichs


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017141256.ga12...@smurf.noris.de

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

Stefano Zacchiroli writes (Re: Re-Proposal - preserve freedom of choice of 
init systems):
 For these reasons, and no matter what went wrong in the past with
 previous attempts at this GR, I think you should have at the very least
 included an applies only to jessie + 1 provision in your proposal.
 Doing so would have disentangled this matter from the upcoming freeze,
 which, per se, is a well-known cause of stress for the project.

The problem with making it simply not apply to jessie is that there
would be a continued opportunity to create `facts on the ground' which
make it difficult to disentangle things in jessie + 1.

But I am not suggesting that the release team ought to apply different
criteria for `jessie-ignore' for RC bugs, for example.

Ian.


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

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

Niels Thykier writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 While I appreciate that this is a very important issue for a lot of
 people, I am deeply concerned by the point in time it is revived.
   _*We have less than 3 weeks till the Jessie freeze starts!*_

I agree that the timing is very regrettable.  You'd have to ask other
people why they didn't second the identical GR in March.


 Honestly, I am interpreting this as a ticking time bomb under the freeze.
 
 Who exactly is volunteering to implement this GR if it goes through?
 Taking GNOME as a hypothetical example[2], suppose it was uninstallable
 without systemd and the GNOME maintainers say We do not want to
 implement this GR[3].

That would depend how easy it would be to fix.

If the fix is easy (for example, the reason it's uninstallable is
because of a dependency declared for political reasons but without
which the actual operation is OK) then it would be a simple matter to
NMU it.

If the fix is not easy then we have three options: the release team
mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
removed from jessie.

I mention the third option not because I think it's what we should do
right now, but to point out that I am not saying that the GNOME team
(or indeed GNOME upstream) have to do any work.  No-one has to do any
work, but if the work goes undone, there are of course consequences to
the affected packages.  If problems persist into jessie+1 I _would_
expect us to seriously consider removing GNOME.

 Then you leave us with a per GR-defined RC buggy default desktop from
 day one of the freeze and no one to clean it up.

Of course I would expect those choosing the default desktop to pick
one that wasn't RC-buggy.

   Be advised that I would very much be inclined to jessie-ignore such
 issues, if such stalemates end up as blockers for the release.

Would it help if we added a note to the GR explicitly saying that this
is what we expect ?

Something like:

   Given the late passage of this resolution, we expect that
   intractable bugs which are RC by virtue only of this resolution
   will be tagged by the release team as `jessie-ignore'.

?

 Beyond that, I would /very much/ like to see guidelines for just how
 much degradation is tolerable.  Honestly, I think this should be a
 part of the GR text.
 
   I do not want to end up as the bad guy having to enforce this GR
 during the freeze, when I most at all really do not want this GR to
 affect Jessie at all.

I'm afraid that explaining guidelines for that seems obviously
impractical to me.

But the backstop is that uninstallability, or complete failure to work
on any system, is obviously RC.  Lack of working power management or
broken suspend would be very annoying but probably not RC.

Ian.


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

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

Adam D. Barratt wrote:
 Note (and this is not splitting hairs) that serious bug is not a direct
 analogue for release-critical bug.

This GR is not amending Debian policy, it's setting a technical
requirement at a more fundamental level, which has never been used to set
technical requirements in Debian before. So it's not clear, at least to
me, that the release team would have the power to make that distinction
if this GR passes.

Bypassing the policy process, locking Debian into a technical decision
which would require another GR to change, etc -- this GR is wading into
uncharted waters without much concern for long term results.

-- 
see shy jo


signature.asc
Description: Digital signature

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

Ian Jackson wrote:
 The problem with making it simply not apply to jessie is that there
 would be a continued opportunity to create `facts on the ground' which
 make it difficult to disentangle things in jessie + 1.

Can you please point to one thing in jessie that is currently entangled
in a way that your proposal would prevent happening?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Dimitri John Ledkov

On 17 October 2014 10:14, Luca Falavigna dktrkr...@debian.org wrote:
 Dears,

 I'd like to draft an alternative proposal to the GR.
 Would anybody consider it a nice addition to the proposals we
 currently have, and eventually second it if I asked for it?

 Of course, improvements to the text are much more than welcome!



 ** Begin Alternative Proposal **

 Proposal: Reaffirm upstream and maintainers technical competence over
 the software they maintain


I do not second this proposal.

I dislike the wording of this proposal. Ideally I would like for
Debian project to evolve and move away from conflict based development
model (upstream vs maintainer vs teams vs TC vs other DDs vs users).
And instead drive towards a more consensus based and shared ownership
development model. However, that's not the problems our developers and
our distribution face today. The proposal as stated, has unbounded
scope, which can be lead to unintended consequences and, in my
opinion, enforces an extended interpretation of DSC/DFSG which we did
not agree upon before.

If your wish to have such a large scope, shouldn't instead the
proposal be to revise the text of the Debian Social contract and/or
Debian Free Software Guidelines?

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhlugq1hcq4esrcsrrsrfxdfk465m-ftcmkbjiykw+4fk...@mail.gmail.com

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

On 10/17/2014 10:33 AM, Ian Jackson wrote:
 If the fix is not easy then we have three options: the release team
 mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
 removed from jessie.

The implication here appears to be troubling for any upstream who wants
to rely on specific features of a given initsystem.

As a developer, i've built tools that were deliberately minimal
*because* i want those tools to rely on functionality provided by the
initsystem of my choice.

Concretely, i've built tools that work only when you have the runit
package installed and functional as the local init system.

The implication of this proposed GR seems to be that those tools would
be unfit for inclusion within debian unless someone erects all the
additional scaffolding that runit provides (process supervision,
pipelined logfiles with autorotation and log msgs just sent to stderr,
restart on abnormal termination, no need for daemonization, clean
process initialization, etc), but does so outside of runit.

I don't think this makes sense -- we should not be rejecting upstream
packages from debian just because they are designed to take advantage of
features of a given init system.

I'm not opposed to helping people work within the confines of whatever
init system they prefer -- one of the things i love about debian is that
i've been able to run machines with runit as pid 1 for many years now.
But i have always understood that if i'm not using the default
initsystem, and something breaks from that interaction, i probably need
to fix it myself (and to submit patches to upstream and/or the debian
package if i want it to work better for other people who also use runit
as pid 1).

This isn't surprising or specific to init systems, of course -- it's how
free software works.

It sounds like there are a lot of people who care about making sure
things work with sysvinit -- that's great, and i hope that energy will
result in more functional sysvinit-based installations.  I'm happy for
us to maintain a healthy diversity, and want to see that work happen.

But i don't think it is (or should be) an RC bug just because your
particular package doesn't support my particular initsystem.

--dkg




signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Ean Schuessler

- Holger Levsen hol...@layer-acht.org wrote:

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

Very well stated. Perhaps a sensible response to this GR is for all of
the maintainers who truly disagree with it to state their intent of
putting their packages up for adoption upon its ratification.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/17457306.37831413558059670.javamail.r...@newmail.brainfood.com

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

Hi,

Brian May:
 If people feel strongly that init system XYZ should be supported, then
 presumably somebody will do the work to make sure it is supported, and it
 does work. As I believe is the case now.

Correct. But this proposal would make *something* RC buggy until *somebody*
writes some software, and it's not at all clear which thing should get the
bug, who that somebody is, or what happens if no *somebody* steps up --
do we drop Gnome? (Or whichever software next exhibits a problem along
these lines.)

In this case, some people stepped up and wrote that something – because
they saw a need for it. Fine, superb, this is how Debian should work.
Did work, even without this GR. What a surprise …

 On another topic, I think we need a GR stating that all software should
 work 100% with any window manager, especially my favourite window manager,
 Awesome.

Same problem. Same solution: either somebody is motivated enough to do the
work (and, hopefully, Upstream will take the patches), or interoperability
will not happen. Making up other issues along these lines is left as an
exercise to the reader.

In either case, a GR forcing RC bugs on the issue is not helpful IMHO.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017151108.gb12...@smurf.noris.de

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 17/10/14 at 16:12 +0200, Matthias Urlichs wrote:
 Hi,
 
 Lucas Nussbaum:
  For example, Ian's software may not require a specific init system to be 
  pid
  1 could be abused by introducing a systemd-clone package in the archive
 
 Please try to ignore maleficial intent and similar failure modes.
 
 If we'd go that way, not only would we need to define (and capitalize)
 every second word, but the GR proposals would be a lot longer – and
 correspondingly harder to understand / apply correctly.

Oh, yes, sure. I'm just pointing out that the current proposals are
quite long and complex (and yes, I'm guilty for that as well), and that
it might be quite hard to understand what they mean in practice.

When proposals will have stabilized, it could be useful to write an
unofficial FAQ to explain what each option really means in practice.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017151516.ga27...@xanadu.blop.info

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

Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 Ian Jackson wrote:
  The problem with making it simply not apply to jessie is that there
  would be a continued opportunity to create `facts on the ground' which
  make it difficult to disentangle things in jessie + 1.
 
 Can you please point to one thing in jessie that is currently entangled
 in a way that your proposal would prevent happening?

As far as I'm aware the current situation in jessie is fine as far as
this GR goes.

There are some bugs with the dependency handling which means that
sometimes the packaging tools do very surprising and undesirable
things, but they are fixable, generally not RC and anyway not directly
addressed by this GR.

So if there is no backsliding, this GR will not delay the jessie
release at all.


However there have been a number of bugs already (now fixed), and
persistent misunderstandings.  For example:

 https://lists.debian.org/debian-devel/2014/10/msg00163.html
   The necessity to depend on (and coexist with) pm-utils is imho
gone with Debian's move to systemd

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762116#11
   The only problem here is trying to support multiple init systems.
Linux is not about choice.

 https://lists.debian.org/debian-devel/2014/10/msg00411.html
   It is there because upstream requires it. There is no GNOME
without systemd. This is not specific to Debian.

In some of these cases the rhetoric is very alarming; others are
mistakes of some kind.  But, it is evident that we have not
communicated clearly enough our commitment to diversity.

Ian.


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

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 10/17/2014 03:44 AM, Lucas Nussbaum wrote:
 Hi,
 
 It is now clear that we will have a vote on this issue. I think that we
 should use this opportunity to clarify the Project's position, and that's
 not something that would be achieved if Further Discussion were to
 win.
 
 I am therefore bringing forward an alternative proposal, deeply inspired
 from the Advice: sysvinit compatibility in jessie and multiple init
 support option of the TC resolution on init system coupling[1], which
 was originally written by Russ Allbery[2] and was then amended by many
 participants to the discussion in February 2014.
 
 [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html
 [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html
 
 - begin proposal -8
 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.  However, the technical
 committee stated in #746715 that [it] expects maintainers to continue to
 support the multiple available init systems in Debian.  That includes
 merging reasonable contributions, and not reverting existing support
 without a compelling reason.
 
 The Debian Project states that:
 
Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built.  There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.
 
Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so.  In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.
 
For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve
or improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and
the package is still basically functional, but Debian's standard
requirement to support smooth upgrades from wheezy to jessie still
applies, even when the system is booted with sysvinit.
 
 The Debian Project makes no statement at this time on sysvinit support
 beyond the jessie release.
 
 
 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 above.
 -- end proposal --8

My understanding is that Lucas clarified currently to mean in wheezy.

I second this proposal.

Thanks for writing it up, Lucas.

--dkg




signature.asc
Description: OpenPGP digital signature

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

Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of 
init systems):
 The implication here appears to be troubling for any upstream who wants
 to rely on specific features of a given initsystem.

Yes, indeed.

 The implication of this proposed GR seems to be that those tools would
 be unfit for inclusion within debian unless someone erects all the
 additional scaffolding that runit provides (process supervision,
 pipelined logfiles with autorotation and log msgs just sent to stderr,
 restart on abnormal termination, no need for daemonization, clean
 process initialization, etc), but does so outside of runit.

But runit is exactly the scaffolding needed to do that, and already
exists!  runit can coexist peacefully with sysvinit, systemd, upstart,
or whatever.  There is no problem depending on runit because runit
doesn't demand being pid 1, so it is nonexclusive.

 This isn't surprising or specific to init systems, of course -- it's how
 free software works.

The problem with init systems is that you can have only one.

If people want to make Debian derivatives that work only with a
particular init system, that's completely fine.  The reverse - trying
to put back support for sysvinit, if it gets taken out of Debian,
would be very very difficult.  As the upstream for our ecosystem, we
in Debian have a special responsibility to retain the flexibility our
downstreams might want.

Ian.


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

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

On 10/17/2014 11:26 AM, Ian Jackson wrote:
 Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of 
 init systems):
 The implication here appears to be troubling for any upstream who wants
 to rely on specific features of a given initsystem.
 
 Yes, indeed.
 
 The implication of this proposed GR seems to be that those tools would
 be unfit for inclusion within debian unless someone erects all the
 additional scaffolding that runit provides (process supervision,
 pipelined logfiles with autorotation and log msgs just sent to stderr,
 restart on abnormal termination, no need for daemonization, clean
 process initialization, etc), but does so outside of runit.
 
 But runit is exactly the scaffolding needed to do that, and already
 exists!  runit can coexist peacefully with sysvinit, systemd, upstart,
 or whatever.  There is no problem depending on runit because runit
 doesn't demand being pid 1, so it is nonexclusive.

nevertheless, runit behaves differently when it is pid 1 than when it is
used in a subordinate role to another initsystem.  If i'm upstream and
i'm building mechanisms that integrate with runit *as it behaves as pid
1*, the implication seems to be that my work would not be welcome in debian.

 This isn't surprising or specific to init systems, of course -- it's how
 free software works.
 
 The problem with init systems is that you can have only one.
 
 If people want to make Debian derivatives that work only with a
 particular init system, that's completely fine.  The reverse - trying
 to put back support for sysvinit, if it gets taken out of Debian,
 would be very very difficult.

i don't think that anyone has tried to remove support for sysvinit for
debian -- i certainly hope the sysvinit maintainers are unlikely to
leave the project or orphan the package.  There may be packages that
don't work as well or integrate as well in a sysvinit-based debian
installation as they do for other choices of pid 1.   But that is also
true if runit is my pid 1 -- some packages won't integrate as well with
my system if i choose this config.  That doesn't mean those packages are
RC-buggy, it means i need to submit servicedirs for them and hopefully
find ways for developers to adopt them.  Or to provide system service
packages that are distinct from packages containing the tools entirely
[0], so that anyone who wants to support service initialization on an
arbitrary initsystem can do so independently.

That said, i don't think that putting back support for sysvinit for
any given package that is unable to currently maintain it would actually
be as difficult as you make it out to be.

 As the upstream for our ecosystem, we
 in Debian have a special responsibility to retain the flexibility our
 downstreams might want.

Yes, we do.  But we also have a responsibility to package and distribute
modern, upstream-maintained versions of useful free software even if
those versions have dependencies that some people might not find
preferable.  We also shouldn't restrain packagers from uploading
software just because they don't have service initialization mechanisms
for every pid 1 that can possibly be used in a debian system.

I like both postgresql and runit, and am really happy that both these
things are in debian.  But postgresql isn't RC-buggy just because the
system service doesn't start automatically when i choose to use runit as
pid 1.

Regards,

--dkg

[0] https://www.debian-administration.org/users/dkg/weblog/53



signature.asc
Description: OpenPGP digital signature

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

2014-10-17 Thread Didier 'OdyX' Raboud

Le vendredi, 17 octobre 2014, 10.00:59 Ean Schuessler a écrit :
 - Holger Levsen hol...@layer-acht.org wrote:
  If you don't like upstreams choices, *you* should write patches. Not
  GRs telling other people to do so.
 
 Very well stated. Perhaps a sensible response to this GR is for all of
 the maintainers who truly disagree with it to state their intent of
 putting their packages up for adoption upon its ratification.

This would only make Debian worse, not better.

Amongst the other problems of this GR, I think this one is the worst 
part: this GR text [0] creates artificial new conditions [1] for 
software acceptable in Debian, both for new software _and_ for existing 
ones. This implies that the best ${insert-your-tech-here} since slice 
bread only working with one init system [2] would _not_ be acceptable in 
Debian until someone does the work to make it non-init specific, even 
if no one would ever imagine using said ${insert-your-tech-here} in that 
context. We'd be severely moving away from a patches welcome culture, 
which I feel, does quite essentially define our mode of collaboration. 
We'd be moving to a culture where perfect(ly init-agnostic) would be the 
enemy of good and where we put the burden of making sure corner-cases 
work not on the ones experiencing the corner-cases, but on the 
maintainers. I'm unhappy about that and will not vote in favour of this 
proposal.

Cheers,
OdyX

[0] 21567.57029.724173.958...@chiark.greenend.org.uk
[1] On top of our usual set: DFSG, maintainability, security, etc.
[2] Which might happen to be why it's so much better: better integration 
across the stack.


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/56544976.cMIKFiWbv4@gyllingar

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

Ian Jackson wrote:
 Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init 
 systems):
  Ian Jackson wrote:
   The problem with making it simply not apply to jessie is that there
   would be a continued opportunity to create `facts on the ground' which
   make it difficult to disentangle things in jessie + 1.
  
  Can you please point to one thing in jessie that is currently entangled
  in a way that your proposal would prevent happening?
 
 As far as I'm aware the current situation in jessie is fine as far as
 this GR goes.
[..]
 So if there is no backsliding, this GR will not delay the jessie
 release at all.

But, the resolution of this GR and the start of the freeze cooincide,
+-1 week. And after the freeze, the chances of backsliding being
allowed, after release team review, are minimal.

-- 
see shy jo


signature.asc
Description: Digital signature

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

Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of 
init systems):
 nevertheless, runit behaves differently when it is pid 1 than when it is
 used in a subordinate role to another initsystem.  If i'm upstream and
 i'm building mechanisms that integrate with runit *as it behaves as pid
 1*, the implication seems to be that my work would not be welcome in debian.

Are you saying that a daemon author would want to write code which
only worked if runit was pid 1 ?

This question of daemon startup is a red herring, I think.  It is
generally easy to solve the problem with some kind of wrapper or tool,
even if a daemon only starts up in a particular way.

 I like both postgresql and runit, and am really happy that both these
 things are in debian.  But postgresql isn't RC-buggy just because the
 system service doesn't start automatically when i choose to use runit as
 pid 1.

postgresql wouldn't be RC-buggy if it _never_ started automatically.
That would just be an annoying bug.

And the GR text is quite careful: it doesn't say that failure to work
with one init system is worse than any other bug.  It is only
_requiring a specific init system to be pid 1_ which is forbidden.

That's the exactly correct criterion because it is pid 1 which you can
only have one of.  A user can have as different non-pid-1 daemon
supervisors as they like so there is no problem with a daemon
requiring a particular supervisor - provided that supervisor can work
(well enough) when not pid 1.

Ian.


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

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

Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 Ian Jackson wrote:
  So if there is no backsliding, this GR will not delay the jessie
  release at all.
 
 But, the resolution of this GR and the start of the freeze cooincide,
 +-1 week. And after the freeze, the chances of backsliding being
 allowed, after release team review, are minimal.

So your objection to the GR is that it is a no-op ?

Other people are objecting on the grounds that the sky would fall.

Ian.


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

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

Ian Jackson writes (Re-Proposal - preserve freedom of choice of init systems):
 ** Begin Proposal **

I am considering making an amendment to this along the lines below.

Please let me know ASAP what you think.  Feel free to use private
email.  Especially, I would like to hear from:

 - People who seconded the original version: are you satisfied
   that with these amendments it still does the job ?

 - Lucas and people who have seconded Lucas's version, or who are
   opposed to the GR on timing grounds: would this go far enough for
   you to support my version, or feel Lucas's alternative is
   unnecessary ?

I intend to make a decision about this in the next 36-48h.  I will
send a copy of this by private email to my seconders.


 2. Loose coupling of init systems
...

Insert new numbered section:

 3. As far as we are aware there are currently (17th of October) no
bugs in jessie which would be declared RC by this GR.

Given the late passage of this resolution, we expect that any
intractable bugs which are RC by virtue only of this resolution
would be tagged by the release team as `jessie-ignore'.

So this proposal is not thought to add blockers to the jessie
release.

And renumber section 3 to 4.

Thanks,
Ian.


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

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

On 10/17/2014 12:06 PM, Ian Jackson wrote:
 Daniel Kahn Gillmor writes (Re: Re-Proposal - preserve freedom of choice of 
 init systems):
 nevertheless, runit behaves differently when it is pid 1 than when it is
 used in a subordinate role to another initsystem.  If i'm upstream and
 i'm building mechanisms that integrate with runit *as it behaves as pid
 1*, the implication seems to be that my work would not be welcome in debian.
 
 Are you saying that a daemon author would want to write code which
 only worked if runit was pid 1 ?

Consider a tool that integrates in some way with /etc/runit/1 or
/etc/runit/2 or /etc/runit/3, which are only relevant for systems with
runit as pid 1 (see runit(8) for more details).  Such a tool should not
be RC-buggy just because it's useless on a system that uses systemd or
sysvinit.

 This question of daemon startup is a red herring, I think.  It is
 generally easy to solve the problem with some kind of wrapper or tool,
 even if a daemon only starts up in a particular way.

so to be clear, it's not (and shouldn't be) an RC bug if a service fails
to start automatically on a system with a non-default init system, right?

 I like both postgresql and runit, and am really happy that both these
 things are in debian.  But postgresql isn't RC-buggy just because the
 system service doesn't start automatically when i choose to use runit as
 pid 1.
 
 postgresql wouldn't be RC-buggy if it _never_ started automatically.
 That would just be an annoying bug.

I'm glad to hear that.

 And the GR text is quite careful: it doesn't say that failure to work
 with one init system is worse than any other bug.  It is only
 _requiring a specific init system to be pid 1_ which is forbidden.

If the requirement is testing a literal string match against
/proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's
pretty silly, and surely that's *already* a bug that upstream would be
grateful for a fix.  in this case, we don't need a GR.

But if the requirement is hey, i'm not going to work without something
else on the system performing functionality X, and a given init system
*doesn't provide* functionality X, then it sounds like either a bug in
the lacking initsystem (should provide functionality X), or a
straightforward case of an explicit dependency.  It could also be
resolved by making some part of the dependent package's functionality
more limited in scope, and saying we can run but we can't to Y if we
don't have access to system functionality X.  These are all legitimate
options for resolving the problem, and they're already available to
folks who want to work on them today.  It sounds like the gdm issue was
actually resolved already through some combination of these approaches
(thanks to Aigars for the recap upthread).  Why do we need a GR that's
unlikely to change this situation?

 That's the exactly correct criterion because it is pid 1 which you can
 only have one of.  A user can have as different non-pid-1 daemon
 supervisors as they like so there is no problem with a daemon
 requiring a particular supervisor - provided that supervisor can work
 (well enough) when not pid 1.

we also limit debian systems to only one mail-transport-agent (e.g. exim
or postfix or courier, but not two of them at once), but we don't say
that mta-specific packages are RC-buggy, even if someone who has a
courier installation would really like to use a tool that currently only
integrates into postfix's mail-handling flow.

I'm going to stop commenting on this thread now and try to fix some bugs
that need fixing before the freeze.

Ian, thanks for raising the concern, and Lucas, thanks for floating an
alternative option.  I hope we can spend our limited time fixing
existing bugs and working well together.

--dkg



signature.asc
Description: OpenPGP digital signature

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

On 17/10/14 at 17:29 +0100, Ian Jackson wrote:
  3. As far as we are aware there are currently (17th of October) no
 bugs in jessie which would be declared RC by this GR.
 
 Given the late passage of this resolution, we expect that any
 intractable bugs which are RC by virtue only of this resolution
 would be tagged by the release team as `jessie-ignore'.
 
 So this proposal is not thought to add blockers to the jessie
 release.
 
 And renumber section 3 to 4.

If you agree that this is only a matter of general technical policy, and
that the current state of jessie matches what you would like to see
after your proposal, couldn't we just agree to withdraw both proposals
now, and discuss what to do for jessie+1 later?

If someone makes changes to dependencies between their packages and init
systems that break this statu quo in jessie, you could still reintroduce
your GR proposal during the freeze. But I think that this threat would
be enough to maintain statu quo until we release (also, it is unlikely
that the release team would allow such changes to be introduced during
the freeze).

What do you think?

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017165421.ga31...@xanadu.blop.info

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

2014-10-17 Thread Thomas Goirand

On 10/17/2014 03:09 AM, Adam D. Barratt wrote:
 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

And therefore, having this GR now shouldn't be a problem.

To me, it's perfectly fine to decide now that we don't want tight
coupling with systemd (and therefore, try to fix these issues when we
can), as long as we also decide that it's not going to delay the
release. And since it's the release team who has the decision power, I
can only see it happening the correct way.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544149e7.5090...@debian.org

Can I vote?

2014-10-17 Thread Gonzalo Velasco C.

Dear Debian friends,
I am not a (registered) part of the team, so I can't vote for the proposal
in https://lists.debian.org/debian-vote/2014/10/msg1.html

But, I'm an user with ~15 computers at the university and home, running 80%
of them some Debian derivative (SolydXK, MiniNo, Ubuntu, Xubuntu). And more
important than that, I am a GNU/Linux fan, enthusiast and promoter. I have
brought a lot of people to GNU/Linux arguing is safer, free and respect our
freedom.

Well, thanks to *the market wishes* of Red Hat, that pushed their systemd
stuff into us, we are now limited not only in init systems inside the
Debian ecosystem, but in a lot of things that not-init-system-only daemon
is eating.

People using it seem *superficially* happy, except system administrators
and freedom fighters. The choices are narrowing down. The whole security
and stability could be damaged with time (if this part is broken or
corrupted, how is our system to behave?).
I hear and read a lot of much more experienced users and IT people arguing
that this is going to become worst.

Debian is a big boy in GNU/Linux, not a sheep! Will it just follow wherever
Red Hat decides to take things - on containers, virtualisation, etc.!!??

Ubuntu's Upstart was not well received by Debian. SysVinit it was said to
be archaic and one man, not worth reinforcing. I humbly think this was
not good and, yet, there are other options (OpenRC by Gentoo...!? whatever).

Please, Debian, keep being THE GNU/Linux free and libre distribution. It is
not about making a war on RH. Let them be what they want. It is about
joining forces with other distros that are not selfish as RH is being.
Debian + Ubuntu +Mint = 80% of the GNU/Linux users on this planet!

Thank you.

   Gonzalo


-- 
Dr. Gonzalo Velasco Canziani
Universidade Federal do Rio Grande (FURG)
Brasil

“The world is a dangerous place to live;
not because of the people who are evil,
but because of the people who don't do anything about it.”
Albert Einstein

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

Ian Jackson wrote:
 Joey Hess writes (Re: Re-Proposal - preserve freedom of choice of init 
 systems):
  Ian Jackson wrote:
   So if there is no backsliding, this GR will not delay the jessie
   release at all.
  
  But, the resolution of this GR and the start of the freeze cooincide,
  +-1 week. And after the freeze, the chances of backsliding being
  allowed, after release team review, are minimal.
 
 So your objection to the GR is that it is a no-op ?
 
 Other people are objecting on the grounds that the sky would fall.

The GR is clearly not a no-op post-jessie. But we're supposed to be
getting ready to release jessie now. The timing is off.

-- 
see shy jo


signature.asc
Description: Digital signature

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

Lucas Nussbaum writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 If you agree that this is only a matter of general technical policy, and
 that the current state of jessie matches what you would like to see
 after your proposal, couldn't we just agree to withdraw both proposals
 now, and discuss what to do for jessie+1 later?
 
 If someone makes changes to dependencies between their packages and init
 systems that break this statu quo in jessie, you could still reintroduce
 your GR proposal during the freeze. But I think that this threat would
 be enough to maintain statu quo until we release (also, it is unlikely
 that the release team would allow such changes to be introduced during
 the freeze).
 
 What do you think?

I can see why that is tempting.

But this resolution is not only important within Debian, and not only
for jessie.

It is also important feedback for upstreams, and our peer distros and
downstreams.  At the moment there is a prevailing rhetoric that
systemd is inevitable and everyone will (have to) be using it.  The
TC's decision in February lent weight to that impression
(inadvertantly but entirely predictably).  This impression has been
repeatedly put forth on Debian lists, and indeed elsewhere.  (I gave
some references earlier.)

And this GR is also important for jessie+1 and the future generally.
I don't want to postpone having this conversation until things have
become yet more difficult, and face the argument that what we want is
impossible for jessie+1.

If there is a problem with this GR it is that it is too late.  Making
it later is just going to allow the dispute to escalate.  And in the
meantime we will have to put up with endless guerilla warfare from the
various camps.

Ian.


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

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

2014-10-17 Thread Thomas Goirand

On 10/17/2014 05:14 PM, Marco d'Itri wrote:
 aigar...@debian.org wrote:
 
 To be frank, in cases like logind I would expect the logind binary
 package to be split out and its source patched in such a way to allow
 it to work without systemd running (however badly) and moving the main
 systemd package from Dependencies to Recommended.
 It is quite clear that the real world does not and will not meet your
 expectations, because logind is not released this way and is not
 packaged this way.
 Now what?

Now, if we can't get the patches we need in the original sources, we
deal with such a non-cooperative upstream and do what's needed on the
packaging side. That's not the first time, and it wont be the last, and
it's not even specific to systemd.

Thomas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54414d8c.7080...@debian.org

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

2014-10-17 Thread Miles Fidelman

Holger Levsen hol...@layer-acht.org mailto:holger%40layer-acht.org 
wrote:



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?


That's an awfully good reason FOR pushing the GR now.

The TC stated, and passed a resolution to the effect of Debian 
continuing to support multiple init systems.  If, as you say, Gnome 
right now is installable with systemd-shim + sysvinit,  those sound 
like release critical bugs in Gnome and/or systemd-shim - and precisely 
a reason to resolve this issue now, not kick it down the road.


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


Some us us want to continue to run production servers, w/o having major 
changes foisted on our systems - which, at the very least, will require 
significant testing, and possibly reconfiguration.


Breaking backwards compatibility is big deal.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54414eb9.9040...@meetinghouse.net

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

2014-10-17 Thread Kurt Roeckx

On Fri, Oct 17, 2014 at 04:05:20PM +0900, Arnaud Fontaine wrote:
 Seconded.

This seems to be signed with a key that is not in the keyring.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017172745.ga10...@roeckx.be

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Kurt Roeckx

On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote:
 On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote:
  I am therefore bringing forward an alternative proposal
 
 Recieved, and verified. Note, this has been proposed by the current
 Project Leader, and thus does not require seconds, but will record those
 seconding anyway.

I don't see him doing it with his DPL hat on, so Lucas can you
clarify that you do this as DPL or not?  (But there seem to be
enough seconds, so it doesn't seem to matter.)


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017174252.gb10...@roeckx.be

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

2014-10-17 Thread Adam D. Barratt

On Fri, 2014-10-17 at 13:15 -0400, Miles Fidelman wrote:
 The TC stated, and passed a resolution to the effect of Debian 
 continuing to support multiple init systems.  If, as you say, Gnome 
 right now is installable with systemd-shim + sysvinit,  those sound 
 like release critical bugs in Gnome and/or systemd-shim - and precisely 
 a reason to resolve this issue now, not kick it down the road.

I think you may be confused about what Holger wrote. You appear to be
arguing that *things working* is a release critical bug.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413568133.2260.27.ca...@adam-barratt.org.uk

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

2014-10-17 Thread Jonas Smedegaard

Quoting Daniel Kahn Gillmor (2014-10-17 18:38:35)
 On 10/17/2014 12:06 PM, Ian Jackson wrote:
 And the GR text is quite careful: it doesn't say that failure to work 
 with one init system is worse than any other bug.  It is only 
 _requiring a specific init system to be pid 1_ which is forbidden.

 If the requirement is testing a literal string match against 
 /proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's 
 pretty silly, and surely that's *already* a bug that upstream would be 
 grateful for a fix.  in this case, we don't need a GR.

 But if the requirement is hey, i'm not going to work without 
 something else on the system performing functionality X, and a given 
 init system *doesn't provide* functionality X, then it sounds like 
 either a bug in the lacking initsystem (should provide functionality 
 X), or a straightforward case of an explicit dependency.  It could 
 also be resolved by making some part of the dependent package's 
 functionality more limited in scope, and saying we can run but we 
 can't to Y if we don't have access to system functionality X.  These 
 are all legitimate options for resolving the problem, and they're 
 already available to folks who want to work on them today.  It sounds 
 like the gdm issue was actually resolved already through some 
 combination of these approaches (thanks to Aigars for the recap 
 upthread).  Why do we need a GR that's unlikely to change this 
 situation?

We need the GR to ensure situation stays good.  No big deal.


 I'm going to stop commenting on this thread now and try to fix some 
 bugs that need fixing before the freeze.

Me too :-)


 - 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
Description: signature

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

2014-10-17 Thread Kurt Roeckx

On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote:
 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:
[...]
 3. Notes and rubric
 
   This resolution is a Position Statement about Issues of the Day
   (Constitution 4.1.5)

I think those 2 conflict, and that if you want to use the TC
powers it would fall under 4.1.4.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017180549.ga16...@roeckx.be

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

Kurt Roeckx writes (Re: Re-Proposal - preserve freedom of choice of init 
systems):
 I think those 2 conflict, and that if you want to use the TC
 powers it would fall under 4.1.4.

Kurt, we had that conversation in March.  Can you please go back and
read the thread then ?  After that extended conversation, you wrote
this, which ended the subthread:

  From: Kurt Roeckx k...@roeckx.be
  To: Ian Jackson ijack...@chiark.greenend.org.uk
  Cc: debian-vote@lists.debian.org, debian-proj...@lists.debian.org
  Subject: Re: Proposal - preserve freedom of choice of init systems
  Date: Mon, 3 Mar 2014 22:05:32 +0100

  On Mon, Mar 03, 2014 at 11:39:40AM +, Ian Jackson wrote:
  [...]
   Does that mean that you are now tending towards the view that
   Matthew's proposal requires only a simple 1:1 majority ?

  Yes.

  Kurt

Ian.


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

Re: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain

2014-10-17 Thread Gergely Nagy

Luca Falavigna dktrkr...@debian.org writes:

 I'd like to draft an alternative proposal to the GR.
 Would anybody consider it a nice addition to the proposals we
 currently have, and eventually second it if I asked for it?

I'd second this proposal.

-- 
|8]


pgpd8kf_TBaYa.pgp
Description: PGP signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

Lucas Nussbaum wrote:
 It is now clear that we will have a vote on this issue. I think that we
 should use this opportunity to clarify the Project's position, and that's
 not something that would be achieved if Further Discussion were to
 win.
 
 I am therefore bringing forward an alternative proposal, deeply inspired
 from the Advice: sysvinit compatibility in jessie and multiple init
 support option of the TC resolution on init system coupling[1], which
 was originally written by Russ Allbery[2] and was then amended by many
 participants to the discussion in February 2014.

I am very uncomfortable with GRs being used to set technical policy. 
We have never before has a GR that did so. It can lock us into technical
decisions which we then need a whole other GR process to get us out of.
And mass voting on technical minutia is no way to run a distribution.

Why not just make your proposal be something along the lines of
reaffirming the technical decision-making process as it currently
stands, from the package maintainers, to the policy, to the TC.
It could implicitly or explicitly reaffirm both recent TC decisions on
init systems.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

2014-10-17 Thread Ansgar Burchardt

Hi,

Joey Hess jo...@debian.org writes:
 Lucas Nussbaum wrote:
 I am therefore bringing forward an alternative proposal, deeply inspired
 from the Advice: sysvinit compatibility in jessie and multiple init
 support option of the TC resolution on init system coupling[1], which
 was originally written by Russ Allbery[2] and was then amended by many
 participants to the discussion in February 2014.

 I am very uncomfortable with GRs being used to set technical policy. 
 We have never before has a GR that did so. It can lock us into technical
 decisions which we then need a whole other GR process to get us out of.
 And mass voting on technical minutia is no way to run a distribution.

The GR about DMs[1] did set technical policy in so far as it prescribed
technical details of the initial implementation, including for example
the DM-Upload-Allowed: yes field.

However it implicitly allowed changing the details later without a GR by
just setting inital policy.

Maybe something similar could be done here?

Ansgar

  [1] https://www.debian.org/vote/2007/vote_003


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94uedqk@deep-thought.43-1.org

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

Ansgar Burchardt writes (Re: Alternative proposal: support for alternative 
init systems is desirable but not mandatory):
 However it implicitly allowed changing the details later without a GR by
 just setting inital policy.
 
 Maybe something similar could be done here?

I think that if the TC wanted to, it could update or change the
policy set by this GR.  After all the GR works by exercising the TC's
powers pursuant to the February TC resolution.  And the TC can amend
its own decisions.

Ian.


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

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory