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

2014-10-23 Thread Olav Vitters 
On Thu, Oct 23, 2014 at 08:38:36PM +0530, Ritesh Raj Sarraf wrote:
> On Thursday 23 October 2014 06:08 PM, Olav Vitters wrote:
> > On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote:
> >> > The same applies to many upstream developers, they develop software
> >> > mainly for themselves, not the users, see for example the latest
> >> > development of Gnome. The only way to change this is by creating a large
> >> > enough user group taking side by refusing to use software that is going
> >> > in the wrong direction and promote alternatives.
> > This is not a "I don't like the GNOME developers" mailing list. "Going
> > in the wrong direction": opinion, not fact. Obviously you can use
> > something other than GNOME, I'd appreciate not generalizing the hundreds
> > people who contribute to GNOME.
> >
> > Similarly, turning not being able to vote into "Debian doesn't care for
> > it's users": You're free to make your case. Convince others.
> > That'll probably be appreciated way more than negativity.
> 
> What was wrong with Svante's post ? He was just giving an example,
> quoting Gnome.
> I'd give a similar example for KDE.

Users aren't second class citizens in GNOME. Contributors have more
influence. Read e.g.
https://en.wikipedia.org/wiki/Second-class_citizen
"are often subject to mistreatment or neglect at the hands of their
 putative superiors"

If that wasn't the intention, ok, but that is what was written and I
assumed it the writer knew the meaning.



-- 
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/20141023212200.gc32...@bkor.dhs.org

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

2014-10-23 Thread Vittorio Beggi (Gmail) 
Ian Jackson's proposal to preserve freedom of choice of init systems 
.


I definitely agree with the proposal.

--
Vittorio Beggi

PHX di Beggi Vittorio
via Cirenaica, 6
35141 Padova PD
Tel/Fax: 049 8756276
Mobile: 340 4871253
mailto: vittorio.be...@gmail.com
www.prontosoccorsopc.biz

Re: Tentative summary of the amendments

2014-10-23 Thread Aigars Mahinovs 
On 23 October 2014 22:17, Uoti Urpala  wrote:
> The essential part was what you cut away:
>
>> > So you agree that there is no fundamental problem with packaging
>> > software that requires either systemd or uselessd? Does the GR still
>> > require "someone"(tm) to package uselessd for Debian before
>> > packaging
>> > that other (fundamentally OK even by your standards) software is
>> > allowed? To polish uselessd integration until it's actually a usable
>> > init system in Debian? I assume you are not volunteering for this
>> > work?
>
> In another mail, Ian said that his interpretation is that the init
> system would not only have to be packaged in Debian, but in testing and
> not RC buggy.
>
> So even GR proponents agree that software which works with either
> systemd or uselessd would be fine. Yet they want to FORBID packaging
> such software, unless someone packages and integrates uselessd for
> Debian. That's a large amount of work which would be mostly unrelated to
> the software running under those systems. And the proponents are not
> volunteering to do such work.

Software that works with either systemd or uselessd would be just
fine, exactly because the extra effort that it would take to make it
work with uselessd. That is because (as you show in the continuation
of your email) this extra work (like implementing the systemd-shim)
would also allow the same functionality to be used with any other init
system. And that is the whole reason for requiring that. One the
sotware is implemented with proper init-system-independance then all
init systems benefit from that.

>> I think that practical effect would be the same if we mandated
>> "support running with at least one non-default init system at PID 1"
>> or "support running with sysvinit at PID 1" or "support running with
>> any init systems in the archive at PID 1" from the point of view of
>> software being able to start with an alternative init system managing
>> the installation (not from the point of view of having init scripts
>> for all init systems).
>
> That's kind of backwards - the practical effect of the GR is pretty much
> to require that everything must implement sysv scripts,

No - you don't have to implement the startup scripts. But you must
make it possible for the startup scripts to be implemented by not
depending on availability of init-system-specific APIs (as in - have
checks and fallbacks for cases where they are not available).

> while there are
> init features that should not be considered to be/remain specific to
> systemd but sysvinit does not support. For example, any init system that
> Debian might want to switch to in the future will support systemd-style
> socket activation.

Actually - no. It is quite possible that next perfect init system
supports none of the systemd functions and even if it supports them,
it is likely that it will have a different API. Relying on a specific
API until it is an actual standart with a widespread implementation
across a majority of alternatives needlessly ties us down to what
systemd does currently. Even systemd itself might decide to change
some of its APIs at some point. Thus the actual functionality of
software should not depend on the existance of a particular API. It is
fine for socket activation feature not to work if that API is changed.
It is not ok for the software to refuse to work at all if that API is
changed.

-- 
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/cabpywdua5yo01vboa5iemsg2br+om-yqpzo+abrjmy1rw0l...@mail.gmail.com

Re: Tentative summary of the amendments

2014-10-23 Thread Uoti Urpala 
On Wed, 2014-10-22 at 22:25 +0300, Aigars Mahinovs wrote:
> On 22 October 2014 20:14, Uoti Urpala  wrote:
> > Ian Jackson wrote:
> >> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> >> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
> >> > > I believe Ian's intended reading is that a package that depends on
> >> > > uselessd | systemd (but does not work with sysvinit) would be allowed
> >> > > by his proposal.
> >>
> >> Yes.
> >>
> >> In practice such packages are not going to be a big problem because
> >> writing init scripts for them would be straightforward, and then the
> >> dependency could be relaxed.
> >
> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd?
> 
> That would not be a problem, because uselessd is only an init system
> and does not include all the extra services that systemd does, for

You're not replying to what was the point of that paragraph. I was not
arguing that the GR might fail to outlaw things its proposers dislike.
The essential part was what you cut away:

> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd? Does the GR still
> > require "someone"(tm) to package uselessd for Debian before
> > packaging
> > that other (fundamentally OK even by your standards) software is
> > allowed? To polish uselessd integration until it's actually a usable
> > init system in Debian? I assume you are not volunteering for this
> > work?

In another mail, Ian said that his interpretation is that the init
system would not only have to be packaged in Debian, but in testing and
not RC buggy.

So even GR proponents agree that software which works with either
systemd or uselessd would be fine. Yet they want to FORBID packaging
such software, unless someone packages and integrates uselessd for
Debian. That's a large amount of work which would be mostly unrelated to
the software running under those systems. And the proponents are not
volunteering to do such work.

> example - logind is not a part of uselessd. Therefore, even if
> uselessd is packaged tomorrow, there would still be just one init
> system in Debian implementing this feature. So the Ians proposal makes
> it a bug to depend on features that are only implemented in one init

This is technically inaccurate. Logind is used under other init systems
with cgmanager+systemd-shim (otherwise the claim that this GR would make
no difference for Jessie could not be true). Also, logind is not part of
the systemd init process either; it only requires the system to support
APIs that other init systems lack. So whether logind is shipped as a
"part of" uselessd doesn't necessarily matter much. I don't know whether
uselessd retains the APIs required by logind.


> I think that practical effect would be the same if we mandated
> "support running with at least one non-default init system at PID 1"
> or "support running with sysvinit at PID 1" or "support running with
> any init systems in the archive at PID 1" from the point of view of
> software being able to start with an alternative init system managing
> the installation (not from the point of view of having init scripts
> for all init systems).

That's kind of backwards - the practical effect of the GR is pretty much
to require that everything must implement sysv scripts, while there are
init features that should not be considered to be/remain specific to
systemd but sysvinit does not support. For example, any init system that
Debian might want to switch to in the future will support systemd-style
socket activation. Uselessd probably supports it. Of course, support for
socket activation could be implemented on top of sysvinit - but AFAIK
the GR proponents are not volunteering to implement that either.

Before Debian selected its next init system, there were three that could
reasonably work for a distro like it: sysvinit, Upstart and systemd.
Most of developers and all of tech-ctte agreed that sysvinit is outdated
and it was a choice between Upstart and systemd. Now Upstart is not a
real alternative any more, and no new system has risen to the status of
a credible contender yet. The GR talks about alternative init systems in
general, and tells people that they must support at least two, any two
they like. In practice it allows selecting any two from the set
{systemd, sysvinit}. 

By making the hurdle as high as requiring that the alternative init
systems have actually been packaged and integrated in Debian, the
practical effect of the GR is pretty much "must support sysvinit", tying
Debian down to support an obsolete system (which even the GR proposer
agreed "has many longstanding bugs and deficiences", at least before he
knew that the only remaining alternative was systemd).



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

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

2014-10-23 Thread Lars Wirzenius 
Hi, Svante,

I fear your wonderfully terse phrasing may cause some people to react
more negatively to what you said than you perhaps intended. Please
forgive me for the boldness of suggsting alternate phrasings below, in
the hope of clarifying things for everyone.

Svante Signell:
> It is well known that the users are second class citizens with respect
> to Debian.

I suggest, instead:

It is well known that in Debian, most of the time, those who do
the work get to make the decisions. Since almost all work in
Debian is done by volunteers in their free time, it would indeed
be strange to require that other people could dictate what they
do. It would not be fun for long to be a Debian contributor, if
any random person on the Internet could order them to do
something, at the random person's whim, on pain of insults and
harrassment.

Users are very important to Debian developers, and it even says so
in the social contract the Debian project has published. Its users
can have a big impact on how Debian gets developed in the future,
when they join development discussions to explain their use cases,
needs, and individual situations, and engage the project in a
constructive way. Despite this, Debian quite sensibly sticks to
the principle of "those who do, decide" and only counts votes for
those who've contributed enough to become formal members of the
project.

That's a bit longer, and not nearly as pithy, but I hope it conveys
your intention better.

> The same applies to many upstream developers, they develop software
> mainly for themselves, not the users, see for example the latest
> development of Gnome. The only way to change this is by creating a large
> enough user group taking side by refusing to use software that is going
> in the wrong direction and promote alternatives.

I would phrase this like this, instead:

The same thing applies to everyone who works on free software in
their free time: they'll work on what they want to work on, and if
that is to a random person's liking and benefit, that's a very
lucky random person. Most developers do listen to their users, and
even random passers-by with an opinion, but they don't let them
decide things. However, the developers get a big ego boost from
making something that people like.

A similar thing applies to those who get paid to work on free
software: they work on things their employer wants them to work
on, and perhaps make decisions that benefit their employer more
than a random person. This tends to mean they keep getting paid.

One can imagine a hypothetical situation where random people show
up and demand and insist that they get to decide on what
developers work on, what they do, how they do it, etc. These
people might even be long-time users of the software, who feel
they such a long history with the software, they're entitled to
some decision making power. To make the situation even more
ridiculous, the random people could use really inflammatory
language, such as substituting "wrong" for "I don't like".

This situation would be really stressful and depressing for the
developers, and one would wonder why they would put up with it. It
would be much easier for them to just quit and go demand other
people do what they want.

It's a good thing that's a hypothetical situation, and not
reality. Free software would die if it were reality.

Again, this is a bit long, but sometimes clarity overweights brevity.

If I've managed to misunderstand, or misrepresent, what you meant,
Svante, please forgive me, and post a explanation to correct me.

-- 
http://gtdfh.branchable.com/ -- GTD for hackers
http://obnam.org/ -- HAVE YOU BACKED UP TODAY?


-- 
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/20141023155900.gd4...@exolobe1.liw.fi

Re: Tentative summary of the amendments

2014-10-23 Thread Miles Fidelman 

Ian Jackson wrote:

Hubert Chathi writes ("Re: Tentative summary of the amendments"):

On Tue, 21 Oct 2014 20:09:18 -0700, Nikolaus Rath  said:

I believe Ian's intended reading is that a package that depends on
uselessd | systemd (but does not work with sysvinit) would be allowed
by his proposal.

I would hope that this would not be allowed by Ian's proposal until
uselessd is also in Debian.  In particular, "work with one alternative
init system", I think, *should* imply that the alternative init system
is in Debian.

Yes; I didn't spell that out because I thought it would be obvious.
By `in Debian' in this context we probably mean `in testing and not RC
buggy'.




Frankly, while I'm not eligible to vote, isn't the real message that 
most of us who object to systemd would like to see classic sysvinit 
continue to be supported?  Why be so damned oblique about things?


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/544925fb.5040...@meetinghouse.net

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

2014-10-23 Thread Ritesh Raj Sarraf 
On Thursday 23 October 2014 06:08 PM, Olav Vitters wrote:
> On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote:
>> > The same applies to many upstream developers, they develop software
>> > mainly for themselves, not the users, see for example the latest
>> > development of Gnome. The only way to change this is by creating a large
>> > enough user group taking side by refusing to use software that is going
>> > in the wrong direction and promote alternatives.
> This is not a "I don't like the GNOME developers" mailing list. "Going
> in the wrong direction": opinion, not fact. Obviously you can use
> something other than GNOME, I'd appreciate not generalizing the hundreds
> people who contribute to GNOME.
>
> Similarly, turning not being able to vote into "Debian doesn't care for
> it's users": You're free to make your case. Convince others.
> That'll probably be appreciated way more than negativity.

What was wrong with Svante's post ? He was just giving an example,
quoting Gnome.
I'd give a similar example for KDE.

We believe Debian is more than just a Desktop. And for Desktop too, more
than just Gnome _or_ KDE.


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




signature.asc
Description: OpenPGP digital signature

Re: Tentative summary of the amendments

2014-10-23 Thread Ian Jackson 
Hubert Chathi writes ("Re: Tentative summary of the amendments"):
> On Tue, 21 Oct 2014 20:09:18 -0700, Nikolaus Rath  said:
> > I believe Ian's intended reading is that a package that depends on
> > uselessd | systemd (but does not work with sysvinit) would be allowed
> > by his proposal.
> 
> I would hope that this would not be allowed by Ian's proposal until
> uselessd is also in Debian.  In particular, "work with one alternative
> init system", I think, *should* imply that the alternative init system
> is in Debian.

Yes; I didn't spell that out because I thought it would be obvious.
By `in Debian' in this context we probably mean `in testing and not RC
buggy'.

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

Re: Tentative summary of the amendments

2014-10-23 Thread Hubert Chathi 
On Tue, 21 Oct 2014 20:09:18 -0700, Nikolaus Rath  said:

> Lucas Nussbaum  writes:
>> Q2: support for alternative init systems as PID 1
>> = A2.1: packages MUST
>> work with one alternative init system (in [iwj]) (if you are confused
>> with “one” here, it’s basically fine to read it as “sysvinit”
>> instead. See [10]this subthread for a discussion about this)

> I believe Ian's intended reading is that a package that depends on
> uselessd | systemd (but does not work with sysvinit) would be allowed
> by his proposal.

I would hope that this would not be allowed by Ian's proposal until
uselessd is also in Debian.  In particular, "work with one alternative
init system", I think, *should* imply that the alternative init system
is in Debian.

Ian, as I understand your previous message, you were only addressing the
issue of a non-sysvinit alternative init system, and not a not-in-Debian
alternative init system, so can you clarify your intent regarding how
your proposal would treat init systems that are not in Debian?

-- 
Hubert Chathi  -- Jabber: hub...@uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


-- 
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/87bnp2debu@desiato.home.uhoreg.ca

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

2014-10-23 Thread Olav Vitters 
On Thu, Oct 23, 2014 at 11:55:34AM +0200, Svante Signell wrote:
> The same applies to many upstream developers, they develop software
> mainly for themselves, not the users, see for example the latest
> development of Gnome. The only way to change this is by creating a large
> enough user group taking side by refusing to use software that is going
> in the wrong direction and promote alternatives.

This is not a "I don't like the GNOME developers" mailing list. "Going
in the wrong direction": opinion, not fact. Obviously you can use
something other than GNOME, I'd appreciate not generalizing the hundreds
people who contribute to GNOME.

Similarly, turning not being able to vote into "Debian doesn't care for
it's users": You're free to make your case. Convince others.
That'll probably be appreciated way more than negativity.

-- 
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/20141023123823.ga7...@bkor.dhs.org

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

2014-10-23 Thread Svante Signell 
(unfortunately this mail will probably not result in the correct thread
order. Don't know if the cause is my MUA evolution, or the web
interface of the debian-vote list archives)

> On 2014-10-17 09:35, Hörmetjan Yiltiz wrote:
> Users still cannot vote?
> No.
> 
Hello,

It is well known that the users are second class citizens with respect
to Debian. 

The same applies to many upstream developers, they develop software
mainly for themselves, not the users, see for example the latest
development of Gnome. The only way to change this is by creating a large
enough user group taking side by refusing to use software that is going
in the wrong direction and promote alternatives.


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

Re: Maximum term for tech ctte members

2014-10-23 Thread Svante Signell 
Hello,

Please don't forget to make the number of members in the CTTE an odd
number too, either by adding or removing one member. This was shortly
discussed especially in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+636783#180 onwards
and summarized in #210.

Thanks!


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

Re: Tentative summary of the amendments

2014-10-23 Thread Ian Jackson 
Joey Hess writes ("Re: Tentative summary of the amendments"):
> My understanding though, is that this GR would change a TC decision,
> with the blessing of the TC, such that the GR becomes the new TC
> decision. So the GR result should be no harder to change than any
> other TC decision.

Yes, absolutely.

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

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

2014-10-23 Thread Lucas Nussbaum 
On 23/10/14 at 07:52 +0100, Jonathan Dowland wrote:
> Dear Lucas,
> 
> On Wed, Oct 22, 2014 at 05:22:39PM +0200, Lucas Nussbaum wrote:
> > I think that the current set of options would be a sensible ballot, and
> > I'm not aware of any discussions to add another option, so I'm inclined
> > to shorten the discussion period.
> 
> I hope you consider the point raised in 20141017090800.ga3...@chew.redmars.org
> before taking this action.

Oh, yes, sure. But is this point still valid? My perception is that the
current set of amendments is good enough. But if you were planning to
propose one yourself and haven't had time to do it yet, I am of course
fine to postpone reducing the discussion period, or even not reduce it
at all. It's just that I'm not aware of anyone planning to propose
additional amendments, or additional modifications to the current
amendments.

However, I'd like to point out that there are good reasons to reduce the
discussion period.
There's currently a discussion in the TC about what to do during
upgrades from wheezy to jessie (#765803). It was raised in
<871tq189dh@rover.gag.com> that it could be better to wait for
the outcome of the present GR to vote on a TC resolution. And that TC
resolution could have an impact on the release.

Also, I think that everybody is quite tired of those discussions, and it
would be better to be able to focus on preparing the release rather
sooner than later.

Finally, given that the voting period won't be reduced, it would still
be possible to discuss the merits of each proposal during the beginning
of the voting period, if needed.

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/20141023070742.ga26...@xanadu.blop.info