REISSUED CfV: General Resolution: Init system coupling

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

REISSUED CfV: General Resolution: Init system coupling

Neil McGovern via nm
Note: this is a re-issued CfV, please use the ballot below or your vote
will be rejected. Voting is now open.

     Voting period starts      00:00:00 UTC on Wednesday, November 5th, 2014
     Votes must be received by 23:59:59 UTC on Tuesday, November 18th, 2014

The following ballot is for voting on init system coupling.
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions or problems contact [hidden email].

The details of the general resolution can be found at:
http://www.debian.org/vote/2014/vote_003

NOTE: the ballot below is a very short summary of each option. Voters
are strongly encouraged to read the full options at the URL above.

Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
   [hidden email]
with the subject "gr_initcoupling".

To vote you need to be a Debian Developer.


HOW TO VOTE

First, read the full text of the platform.

To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:

  [hidden email]

The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.

There are 5 choices in the form, which you may rank with numbers between
1 and 5. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice.  Do not enter a number smaller than 1 or larger
than 5.

You may skip numbers, leave some choices unranked, and rank options
equally.  Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.

To vote "no, no matter what", rank "Further Discussion" as more desirable
than the unacceptable choices, or you may rank the "Further Discussion"
choice and leave choices you consider unacceptable blank.  (Note: if the
"Further Discussion" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"Further Discussion" choice by the voting software).

Finally, mail the filled out ballot to: [hidden email].

Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.

NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring.  You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.

The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant).  To avoid problems I suggest you use PGP/MIME.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
57dd4d7c-3e92-428f-8ab7-10de5172589e
[   ] Choice 1: Packages may not (in general) require a specific init system
[   ] Choice 2: Support for other init systems is recommended, but not mandatory
[   ] Choice 3: Packages may require specific init systems if maintainers decide
[   ] Choice 4: General Resolution is not required
[   ] Choice 5: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

----------------------------------------------------------------------

The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1

mQINBFRX47EBEACyQIoQ1G9G36g+5tgZU8yIXIII6uzAG+b9qCv83B6Y3nUTwugt
EgP/6nStrZYunUyPir8e/V5GhPYXxt5bIfAx7+HVdmE5UGH88X3ZWyxblXU4Y7gs
Orbo/5D178uIgpfaKkoCfDMfEnMdsj42IoKLidPuuF0YH+XcYNP7JXi3q8newdMk
jgzpJBmykuyOFL/GhQht5bOz59irkWkfK9IFrrnzE6LFzEC3dAyYUjmI7DLT8M2m
Lgpzzk72SclGHPguJH9rzTycoCk1XYVfmLYgDM/E5VvXgCmE4CyVG2urCf/qkOEp
hLHFZv0NfIihrtT1YsK6+JslnUgwY4Sd0xHEjuZEo6P6tRjdLKdPvg+3dPldjf/b
dtuwZyw4hUJsXYYwYN9l8OQrNfhPcI1+ONIi/Mgh7j2M0cHPx+mHQ4PmQivnLSeg
IxutsIIXjNKoXDvs6SvTdS1S1GrHOJhi66y/oD6TkJ92ONIokRSKS01rK3RtQGNZ
ty1MNDaEMYw3EalO8H4bouPTen1yD4NEfKHqJq1i6XfXvxI2WD2q6sbtq4pM0KYO
AWWG/UEJTolr4GmhbfgGUYWMl1tQENZqqnXbLzXbrkvx8QO6ctmNjOXqiQLPcdyb
D3QoOaETjYZbJBNQm82QNcN/AKZb1bFcxn+udyLndp51x4G2cn8HXftj9QARAQAB
tDlJbml0IHN5c3RlbSBjb3VwbGluZyBHUiA8Z3JfaW5pdGNvdXBsaW5nQHZvdGUu
ZGViaWFuLm9yZz6JAj4EEwECACgFAlRX47ECGwMFCQAVGAAGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJENMz7Ba0rT7DgEYP/REro0zlGHkyYFFvOlFGpmrFNbWE
xkrPh5xS3ywVgnTiEF80xn0afcO3JfC/aOVSoJTFCk2ROerdf9oSzRH/pV67BDlX
LWZxZvUtEAYMoOoJlnk5lxvtplGORRpb8kSq5bGCByjLFiHKOLwt+2SpiWIKlAxe
JFaeccc8o5WraHDwkfQYjjAzKY9WIP7gap8tt2Od+n9Rdj/lqR9lo78mAo5VUzr0
WeyL5DYIdzguCLFBJrrPK9SrbB1XC29MKF9H7ESeoqAyHXb6v1f19gAcRqlEFOqB
QungyCDAye95GujJktWl/SPzv7auzp7Y9iGAaU90gpxz1tf0ciXxebS4yayPjw0J
dygHzJEf/8o/oURH4S3R3c+LoZL+xVbjdgBPQfYDZ9vYq5MB0tzLH9H28i9pPQ1/
ztnfnQlzWPY7DQCF6FqXwnL0dXRAfKgHkkZYkS91W9W0dOK3XvZ8Gba1DiCD7oOz
4yv0M3dVlb2PiGSccINPij5pQiVT5ekz/X7CJmz7wzqMGrjPQq3TU8UpaRlx2nXx
IRIodgWpQoUhRHLp1ig856E8q0jwbogIjE5X/XO6DsOb2KiVodi9XySwxk+qnmlm
7cjc+xyazVGW9fj+PWvRe62V9ieXMgYKgRCWOu9M4tvmo4thsQVAs61FVraHWtT3
9IqRT6aexf8vnhlUiQIcBBABCAAGBQJUV+RuAAoJEH9VuxKkD4Yun5UQAJjQWMGA
CdCdx5coMlN908BtbleqhclYPgZVIiR0BUZN+EwNQu8QLZhf2k+32OBTl5Fmu+7I
TQPcdSvg6tlRG7ddJyMx3g+PgDYEQwbnZlLGXAdtyopll2l7+UKYuEF6VJHeuM00
VTNVXo/L6FnhK7Z4q1QEUsQep/F6sCOsl1EjULJKwTXz91ZXeOIp3M6uhaT4m1rT
qY35uJgqjIXMOst0nfnQZQJL6a6Mh9PfQOwLWoEZY7Dvj/4wjWkCzj8tuhT6T5fL
sPtdW5CipTVCkasS8MrTanfgA4lUcanvCcvBo+8MdSDlj67DPJfQ8OwIJg8MKiT6
BAjNKnCpEQjnGa/LySNwETXZc5qX/tMfU8QTwxectaPKZgNEufu/hq2cxauFPYge
Q7ddWZLrVl6sH6e27Ga2J6zJgKX3jTXgJ97kqx8uiivjTRy1Nw8feTd4HadXAuiH
yY8vUyJZiZynFW3G3smXV++JEjUYBYTRLEOS/ETjh22EiGcHa4j/+0iGJbXMx0oJ
OIm7VIec57gVmyWxY9fCm+r3dtM1rU747oPqFpEAxRLYvWluPdYSWiCWYtxy3rK5
zHFNYJHLHYdCOBd7C1FE5L4OFwBmuyASS399NPuBCIKd7BbpXYZV76Aypwgen0uz
zlYOq13WXyH4U3TrqUYioGo3+f+qDDK+xhoVuQINBFRX47EBEAC4XqVpk9YHbf4v
YFr5iO6nD09NXjuDhhnJJ78mNpbv+vIEG66fAq/o5Ww6J6EXH/hfNwg8atsrgdeW
epO7jMl+jg5Lh1q2jihZagPskrPhK/KbZqIjSiaGEwFWkzQ8Sr2Inf5ehRsDboKQ
1XwI6k/qv+Viz/epI7XDZc1WRDQeMqLki8p4J9JJERiPkV2D73WvNSE1jLmxayjK
fO4WP/jLI1oL2ckAqqw3uYTbCTzXeUc4XALYAGiuC2t7T4N+pW730nuDILFAQsRT
O0JQ1P7cgF8wyO1IBI3FMpwOsYbaqa1EOzIBA8hJDi3eIDWogm4oYXKqDCjiUvHQ
pS2SikKdrDi4Xe5I9Hdl2aVWXxNRbAo1UEAKFhXRghQzij0ihSlaQyRKtN1HOEBO
MohS+5xUKtQJmSqBosb6JVEp38lwnVDHXfYmPeQisVz4//8vGtd3Jwmt5a2CQnR6
HMg+MF4oJMJv3Tm3047RCZz4T8o4oFe9MW14cqOg+BuWaH8fi8xFd99fY24ilNgi
twsZQzSNupKGtlZhbPtUNz3D92EwZOx8okLONB3mCRKsdybOLPZmcjyE3CMddD1c
hWgGspiG3wwCfVKspK8gcqcM22VnECLw1tXffQ2vf271LzuNDLBgqAZ/AyE6All9
ZrquPS61zd6nuqiTuNcxri/Flc3htQARAQABiQIlBBgBAgAPBQJUV+OxAhsMBQkA
FRgAAAoJENMz7Ba0rT7DrsYP+wV6ErY0Yqv7mXUIYPDg0gxNZP2XnU9e/aU/7l9x
Wu2Y/2Q4lBNeZ48SV2fwGFRDdmeZSpBDLXnZzcSTkf36Qlebca3zFDxiyiZ8lkGN
rJJi8una49r95ojURSzWEGREvPb51jmHLIexQlaFqJ0sbvSGx4e7fnrWRwARR+Ua
3opkRlr4rvbsZKEtMQNG/eo6fqMsNiasY8MnQdYl0luvYX16wOj9qEGR1ytd1ymn
FLQQbSc2dA17jpBfe9g6frAr/upKKxCUAfTPRIqHznyLObJBWhgDgsPTHFec03PJ
DRFb4JWB5cGaq8Ym47X/0OXWlTW3LQHIxTFdWYQ1tBCTyNFwhlv5eJc871MUfVff
SkutXlw4KP3I/ZmKViOZ+GBzqmwPLe9S8i4K8s3hZTcuyHQXL/0VrNinByNbDBOE
EcrPA7448u0J46EExtcFGVFDaHWTB6spqh6VLOVE+Z2Tyr/eRUu6uhU6jgXMT/o+
gR+ZI5wrAFd/X7pV6UX7sMm64KIRmjv7n8VfBzrG0evgNkUJ2v2b3xhxYNcYOEOQ
L2u1y9gHG9G8ohrVXR73q/dwCkAdH/Wm9TD3h5VcNTfz8vv3Nui6bgP1k0l38LDI
nvnWwa89pQ5UY9FFy7j7D5oeNokCBVAMXF3zmI6kbIEFO1TCyaDUTZyGG0wrEhVJ
qdlE
=Vgq4
-----END PGP PUBLIC KEY BLOCK-----

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

Re: REISSUED CfV: General Resolution: Init system coupling

Philip Hands

> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 57dd4d7c-3e92-428f-8ab7-10de5172589e
> [ 5 ] Choice 1: Packages may not (in general) require a specific init system
> [ 3 ] Choice 2: Support for other init systems is recommended, but not mandatory
> [ 2 ] Choice 3: Packages may require specific init systems if maintainers decide
> [ 1 ] Choice 4: General Resolution is not required
> [ 4 ] Choice 5: Further Discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

attachment0 (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Didier 'OdyX' Raboud-5
In reply to this post by Neil McGovern via nm
Hi Neil, (CC'ing secretary@)

Le mardi, 4 novembre 2014, 23.53:43 Neil McGovern a écrit :
> The responses to a valid vote shall be signed by the vote key created
> for this vote. The public key for the vote, signed by the Project
> secretary, is appended below.

From what I can see [0], the public key as appended in the CfV is signed
by the assistant secretary, and not by the secretary himself. Although
§7.1.4 allows the secretary to delegate his authority, I think the above
formulation (probably out of a template) was factually wrong. It would
be good if the secretary could also sign this key and send the signature
to the list…

(For the avoidance of doubt: I have no trust issues with the secretary
or his assistant, at all).

Cheers,
OdyX

[0] gpg --list-sigs B4AD3EC3 | grep '^sig' | grep -v gr_initcoupling
sig          A40F862E 2014-11-03  Neil McGovern <[hidden email]>

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

Re: REISSUED CfV: General Resolution: Init system coupling

Philip Hands
In reply to this post by Philip Hands
Hi Neil,


Philip Hands <[hidden email]> writes:

>> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>> 57dd4d7c-3e92-428f-8ab7-10de5172589e
...

Oh, oops!  maybe you should set the Reply-To for bears of little brain
like me.

I'm sure you probably do so normally, and that having to reissue this
was just enough to make it slip your mind. Thanks for dealing with it.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

attachment0 (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Matthias Urlichs-3
In reply to this post by Philip Hands
Hi,

Philip Hands:
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

That CfV should have had a Reply-To: line …

--
-- Matthias Urlichs

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

Re: REISSUED CfV: General Resolution: Init system coupling

Kurt Roeckx
In reply to this post by Didier 'OdyX' Raboud-5
On Wed, Nov 05, 2014 at 08:54:17AM +0100, Didier 'OdyX' Raboud wrote:

> Hi Neil, (CC'ing secretary@)
>
> Le mardi, 4 novembre 2014, 23.53:43 Neil McGovern a écrit :
> > The responses to a valid vote shall be signed by the vote key created
> > for this vote. The public key for the vote, signed by the Project
> > secretary, is appended below.
>
> From what I can see [0], the public key as appended in the CfV is signed
> by the assistant secretary, and not by the secretary himself. Although
> §7.1.4 allows the secretary to delegate his authority, I think the above
> formulation (probably out of a template) was factually wrong. It would
> be good if the secretary could also sign this key and send the signature
> to the list...

I've signed it and updated the ballot to have both signatures.
I've also uploaded that to the keyservers.


Kurt


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Holger Levsen-2
In reply to this post by Neil McGovern via nm
Hi,

After reading https://www.debian.org/vote/2014/vote_003 in full again, I came
to the conclusion that I wanted to publically withdraw my support for Choice 2,
after re-reading it several times and sleeping over it.

So why do I dislike choice 2?

Choice 2 has two paragraphs I disagree with, rather strongly by now:

----begin part 1
   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.
----end part 1

----begin part 2
   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.
----end part 2

So, about part 1 I disagree with telling maintainers what to do, that they
should priorize supporting other init systems. IMO thats a.) completly up
to the maintainer and b.) I think prioritizing security fixes and usability
features and plain simple features is probably most always more beneficial
for the average user. Or: whatever it is, but I hardly doubt it's wise to
always prioritize support for whatever niche initsystem.

So (IMNSHO anymore) this is stupid advice (with a "should" statement no less)
harming our software and our users. I blame lost focus due to a distorted
"discussion" for this.

And part 2 is too vague and broad at the same time, and also unrealistic given
the circumstances (eg wanting to release in 2015). Again, I think these words
aim and prioritize a rather unimportant (and unspecific) feature (and whats a
smooth upgrade anyway? IMO a reboot is part of a smooth upgrade as only after
a reboot I know the system can be rebooted safely...) and take away the
opportunity to do the right thing instead.

Choice 2 is certainly better than choice 1, which completly unacceptably tells
maintainers they have to support (and provide) a removed legacy upstream
feature. Or better: invent a new system which they have no interest to create.
IOW: those who believe in choice 1 think they can tell others to write patches
(and how!). Which is soo much out of bounds with Debians ideals and practices
since over 20 years that I'm speechless.


I'm also utterly disgusted that this GR was proposed by Ian, someone who
perceives himself as loser of the tech-ctte decision (instead of accepting
a group decission of a group which he is part of) and thus deciced to beat
Debian into shape via this GR - and who has already announced that he will
not keep quiet if he looses the GR and only will be quiet if he wins.
(I'm happy to provide the message-id for this... but I'm sure people do
rememeber.)

This makes me quite very sad. From a responsible and reasonable tech-ctte
member I would have expected (and I still expect!) to see the bias and act
accordingly, as in: step back.


cheers,
        Holger

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

Re: Re: REISSUED CfV: General Resolution: Init system coupling

Svante Signell-3
Get real man. This is a very important issue in the whole free software
world. Freedom of choice or not, especially for *nix*.


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Jakub Wilk-4
In reply to this post by Holger Levsen-2
Hi Holger,

I'm afraid that if you want to conduct a personal attack on Ian, you
have to try a little bit harder.

* Holger Levsen <[hidden email]>, 2014-11-08, 20:46:
>I'm also utterly disgusted that this GR was proposed by Ian, someone
>who perceives himself as loser of the tech-ctte decision (instead of
>accepting a group decission of a group which he is part of) and thus
>deciced to beat Debian into shape via this GR

You can't decide such a thing single-handedly. Are you also disgusted
that 11 people seconded Ian's proposal?

>- and who has already announced that he will not keep quiet if he
>looses the GR and only will be quiet if he wins.

Presumably you're referring to
<[hidden email]>. Oh wait, no.

>(I'm happy to provide the message-id for this... but I'm sure people do
>rememeber.)

Please do provide it.

--
Jakub Wilk


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Holger Levsen-2
Hi Jakub,

On Sonntag, 9. November 2014, Jakub Wilk wrote:
> I'm afraid that if you want to conduct a personal attack on Ian, you
> have to try a little bit harder.

I'm not interested in personally attacking Ian. At all. But I do think his
_behaviour_ has been quite unacceptable and also I think it would have been
worse if I had written "some tech-ctte member" or something like this and
avoided naming him. I had such a draft and to me it looked much better when I
added his name.

Elephant in the room also came to my mind…

> Presumably you're referring to
> <[hidden email]>. Oh wait, no.

Indeed. I ment
https://lists.debian.org/21585.4657.229360.683513@...
 
> >(I'm happy to provide the message-id for this... but I'm sure people do
> >rememeber.)
> Please do provide it.


cheers,
        Holger



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

Re: REISSUED CfV: General Resolution: Init system coupling

Holger Levsen-2
In reply to this post by Jakub Wilk-4
Hi again,

after re-reading these threads to find that message-id I missed to reply to
this:

On Sonntag, 9. November 2014, Jakub Wilk wrote:
> You can't decide such a thing single-handedly. Are you also disgusted
> that 11 people seconded Ian's proposal?

no, not at all.


cheers,
        Holger

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

Re: REISSUED CfV: General Resolution: Init system coupling

Michael Meskes
In reply to this post by Jakub Wilk-4
On Sun, Nov 09, 2014 at 01:24:16AM +0100, Jakub Wilk wrote:
> >I'm also utterly disgusted that this GR was proposed by Ian, someone who
> >perceives himself as loser of the tech-ctte decision (instead of accepting
> >a group decission of a group which he is part of) and thus deciced to beat
> >Debian into shape via this GR
>
> You can't decide such a thing single-handedly. Are you also disgusted that
> 11 people seconded Ian's proposal?

What? He can't decide ingle-handedly that he's disgusted? Which content do I miss?

> >- and who has already announced that he will not keep quiet if he looses
> >the GR and only will be quiet if he wins.
>
> Presumably you're referring to
> <[hidden email]>. Oh wait, no.

I'd assume he was referring to:

> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.

> If my GR fails I expect a series of bitter rearguard battles over
> individual systemd dependencies.

This to me reads like the threat Holger mentioned. And for the record, I was
very surprised to this given the history of the decision.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Matthias Urlichs-3
In reply to this post by Holger Levsen-2
Hi,

Holger Levsen:
> After reading https://www.debian.org/vote/2014/vote_003 in full again […]
> […]
> I'm also utterly disgusted that this GR was proposed by Ian […]

Everybody please take a step back and read

>> https://lists.debian.org/debian-project/2014/11/msg00002.html

before continuing this subthread.

In an ideal world, to be frank, you would have done that _instead_of_
starting/continuing this subthread …

--
-- Matthias Urlichs

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

Re: REISSUED CfV: General Resolution: Init system coupling

Jonathan Dowland
In reply to this post by Michael Meskes
On Sun, Nov 09, 2014 at 04:27:21AM +0100, Michael Meskes wrote:

> I'd assume he was referring to:
>
> > If my GR passes we will only have to have this conversation if those
> > who are outvoted do not respect the project's collective decision.
>
> > If my GR fails I expect a series of bitter rearguard battles over
> > individual systemd dependencies.
>
> This to me reads like the threat Holger mentioned. And for the record, I was
> very surprised to this given the history of the decision.

FWIW, I did not read this as a threat, or at least, I did not read it as
suggesting that Ian himself would participate in this bitter rearguard action.
I read this as meaning Ian suspected that unless his GR was carried, various
anti-systemd people would not be mollified and their disagreement would
percolate down to individual packages and bugs, rather than being discussed
(and potentially addressed) at a project-wide level. As such, and I'm assuming
good faith on Ian's part here, I think Ian was trying to describe what he
thought was the likely outcome, and not specifically threaten to behave in a
particular way.


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Lucas Nussbaum-4
In reply to this post by Holger Levsen-2
Hi Holger,

(I'm only answering the first part of your mail -- I don't think that
it's fair to alienate Ian and the supporters of Choice 1. I believe
that they are all acting in good faith, pushing for what they think is
best for Debian, and that their opinions should be respected.)

Here is how I see things.

There are four options on this GR. Choice 4 (which I support and helped
improve, at least IMHO) makes a clear statement about our
decision-making processes and the use of GRs.

The three other choices are different answers to the same set of
questions (see [0] for my personal detailed analysis of those, btw).
I don't think that any of those choices will beat Choice 4, but
Condorcet allows us to rank all options, and I think that the relative
ranking of choices 1, 2, 3 will still be a strong message sent by
Debian.

There are technical decisions in Debian that are easy to make, because
there's one optimal solution. That isn't the case here. There are valid
arguments to support both extremes, which are fairly well represented by
Choice 1 (=~ "we want to keep the ability to choose between init systems,
forever") and Choice 3 (=~ "let's let maintainers decide what is best for
their packages").

In Debian, we have a culture of seeking compromises in such situations,
and that's what Choice 2 is trying to do. It might not the optimal
compromise, but unfortunately, it is too late now to propose another
option. For my defense, I also (mostly) sticked to the wording used by
the TC back in February (see [1] for details and pointers).

The project seem to be heavily divided here. Choosing (1) or (3) would
make the losing camp very unhappy. Even if there's a 80/20 majority for
the winning option, can we afford to disappoint _that much_ 20% of our
contributors? I don't think so.

I would like to stress that the question being asked is not:
A) "what is your personal preference, as user or maintainer?"
But rather:
B) "What is best for Debian, what should Debian do, in your opinion as
    a member of the Debian project?"
(A) is fairly easy to answer. (B) is much harder, and requires one to
consider the long-term consequences on Debian of each possible outcome,
for example.

I don't expect so many people to be super-happy if Choice 2 were to win
against Choices 1 and 3. But I hope that this is an outcome where a lot
of people would think "well, my own preference didn't win, but that
looks like an outcome I can accept."

Let me address your specific points now (reordering paragraphs of
your mail slightly):

> Choice 2 has two paragraphs I disagree with, rather strongly by now:
>
> ----begin part 1
>    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.
> ----end part 1
>
> So, about part 1 I disagree with telling maintainers what to do, that they
> should priorize supporting other init systems. IMO thats a.) completly up
> to the maintainer and b.) I think prioritizing security fixes and usability
> features and plain simple features is probably most always more beneficial
> for the average user. Or: whatever it is, but I hardly doubt it's wise to
> always prioritize support for whatever niche initsystem.
>
> So (IMNSHO anymore) this is stupid advice (with a "should" statement no less)
> harming our software and our users. I blame lost focus due to a distorted
> "discussion" for this.
There are lots of people who care about support for alternative init systems,
for various (often good) reasons. Should Debian completely ignore them? I don't
think so, but YMMV.

On "telling maintainers what to do", that's something we already do in
Debian. Caricaturing a bit, either your packages respect the Policy, or they
are out. One of the key things that Debian provides is standardization (in
packages installation, files layout, software features, etc). We define our own
standards, and apply them to all packages in Debian, even if it sometimes
requires us to disagree with upstreams. There are other distributions that make
different choices. For example, I'm told that Arch puts some emphasis on
following what upstreams decide. Should Debian change it policy to something
more like Arch? I don't think so, but YMMV.

(Also see Steve's mail[2] on the question of compelling maintainers to do work)

On "prioritizing support for init systems that are the default on non-Linux
ports over security fixes or usability features", this GR proposal does not say
anything about this. In some cases, it might make sense to prioritize support
for such init systems over security fixes, but the opposite is also true.
Maybe the wording is not optimal here, but you seem to be over-reading a bit.

> ----begin part 2
>    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.
> ----end part 2
>
> And part 2 is too vague and broad at the same time, and also unrealistic given
> the circumstances (eg wanting to release in 2015). Again, I think these words
> aim and prioritize a rather unimportant (and unspecific) feature (and whats a
> smooth upgrade anyway? IMO a reboot is part of a smooth upgrade as only after
> a reboot I know the system can be rebooted safely...) and take away the
> opportunity to do the right thing instead.
Similarly to the specific paragraph about jessie in Choice 1, I don't
think that this statement about support for sysvinit in jessie (for
packages that supported sysvinit in wheezy) is going to add any
additional work during the freeze, because the current state of jessie
is fine in that regard. That whole paragraph prevents regressions by the
time we release, which is unlikely anyway thanks to the monitoring of
changes by the release team. I don't think it hurts, but it made more
sense in the original TC resolution, when there was a lot more time to
introduce regressions.


Now, as I partially announced my vote in [3], I'd like to say that I
changed my mind a bit. My vote is (currently):
Choice 4 > Choice 2 > Choice 1 > Choice 3 > FD

Details:
--------
I agree with the statement in Choice 4.

Amongst (1), (2), (3), I prefer (2), for the reasons given above.

I ranked all options above FD. I believe that this discussion is so
toxic that any decision is better than more discussion. I think that
we should move on.

(1) and (3) are both options I dislike quite a lot.  I dislike (1)
because, instead of being a technical decision taken about the current
and near-future state of things, it is more a political decision that
strongly binds us to support several init systems for the long-term
future. I would have very much preferred a technical decision about
jessie and maybe jessie+1.

But actually, I dislike (3) even more, for the reasons detailed in the
subthread at [4].  I value standardization a lot. I think that this is
one of the main things that Debian provides. (3) is a big step towards
diminishing the importance of a common policy, by pushing important
technical decisions that affect standardization to the respective
maintainers. I think that all packages must support the default init
system (except in very specific cases), and we shouldn't allow
maintainers to decide otherwise because they think it's best for their
packages. (yeah, the wording in the amendment goes slightly further, but
I don't think it goes far enough -- also, we have existing procedures to
deal with cases where it makes sense to deviate from a common policy).

Lucas

 
[0] http://www.lucas-nussbaum.net/blog/?p=845
[1] https://lists.debian.org/debian-vote/2014/10/msg00043.html
[2] https://lists.debian.org/debian-project/2014/10/msg00078.html
[3] https://lists.debian.org/20141022150745.GB3536@...
[4] https://lists.debian.org/debian-vote/2014/10/msg00261.html

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

Re: REISSUED CfV: General Resolution: Init system coupling

David Weinehall
On Sun, Nov 09, 2014 at 11:34:20AM +0100, Lucas Nussbaum wrote:
[snip]

> But actually, I dislike (3) even more, for the reasons detailed in the
> subthread at [4].  I value standardization a lot. I think that this is
> one of the main things that Debian provides. (3) is a big step towards
> diminishing the importance of a common policy, by pushing important
> technical decisions that affect standardization to the respective
> maintainers. I think that all packages must support the default init
> system (except in very specific cases), and we shouldn't allow
> maintainers to decide otherwise because they think it's best for their
> packages. (yeah, the wording in the amendment goes slightly further, but
> I don't think it goes far enough -- also, we have existing procedures to
> deal with cases where it makes sense to deviate from a common policy).

I too value standardization.  Judging by decisions taking by other large
distributions and upstream development, a fifth, "only support systemd
as init system" would thus have been the most sensible option.  But for
political reasons that's sadly not realistic.

I read option 3 as saying that all packages have to support the default
init system and *on top of that* they may, at the maintainer's
convenience, support other init systems.  This is as close to a more
sensible fifth option we're likely to get at the moment.

Maybe once things have calmed down and people notice that the moon
did not fall just because we changed default init system it might be
viable to formally excise sysvinit scripts, but for now I think that
option 3 is far better than option 2.


Kind regards: David Weinehall
--
 /) David Weinehall <[hidden email]> /) Rime on my window           (\
//  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/    (/   Beautiful hoar-frost       (/


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

Reply | Threaded
Open this post in threaded view
|

Re: REISSUED CfV: General Resolution: Init system coupling

Lucas Nussbaum-4
On 09/11/14 at 13:16 +0100, David Weinehall wrote:
> I too value standardization.  Judging by decisions taking by other large
> distributions and upstream development, a fifth, "only support systemd
> as init system" would thus have been the most sensible option.  But for
> political reasons that's sadly not realistic.
>
> I read option 3 as saying that all packages have to support the default
> init system and *on top of that* they may, at the maintainer's
> convenience, support other init systems.

Unfortunately that's not how the proposer for Choice 3 reads it.
see subthread starting at
https://lists.debian.org/debian-vote/2014/10/msg00179.html
and specifically
https://lists.debian.org/debian-vote/2014/10/msg00181.html

With Choice 3, a package maintainer can decide to support only an init
system that isn't the default if the maintainer considers it a
prerequisite for its proper operation and no patches
or other derived works exist in order to support other init systems
in such a way to render software usable to the same extent.

Lucas

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

Re: REISSUED CfV: General Resolution: Init system coupling

The Wanderer
In reply to this post by Jonathan Dowland
On 11/09/2014 at 05:26 AM, Jonathan Dowland wrote:

> On Sun, Nov 09, 2014 at 04:27:21AM +0100, Michael Meskes wrote:
>
>> I'd assume he was referring to:
>>
>>> If my GR passes we will only have to have this conversation if
>>> those who are outvoted do not respect the project's collective
>>> decision.
>>
>>> If my GR fails I expect a series of bitter rearguard battles
>>> over individual systemd dependencies.
>>
>> This to me reads like the threat Holger mentioned. And for the
>> record, I was very surprised to this given the history of the
>> decision.
>
> FWIW, I did not read this as a threat, or at least, I did not read it
> as suggesting that Ian himself would participate in this bitter
> rearguard action. I read this as meaning Ian suspected that unless
> his GR was carried, various anti-systemd people would not be
> mollified and their disagreement would percolate down to individual
> packages and bugs, rather than being discussed (and potentially
> addressed) at a project-wide level. As such, and I'm assuming good
> faith on Ian's part here, I think Ian was trying to describe what he
> thought was the likely outcome, and not specifically threaten to
> behave in a particular way.
Thank you. I've been trying to think of a way to clearly express that
for some time now, ever since people first started to indicate that they
thought this comment was a threat.

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw


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

Re: REISSUED CfV: General Resolution: Init system coupling

Arno Töll-5
In reply to this post by Lucas Nussbaum-4
Hi,

On 09.11.2014 13:36, Lucas Nussbaum wrote:
> With Choice 3, a package maintainer can decide to support only an init
> system that isn't the default if the maintainer considers it a
> prerequisite for its proper operation and no patches
> or other derived works exist in order to support other init systems
> in such a way to render software usable to the same extent.

Yes. That being said, that's a hypothetical point you're making as we
(hopefully) all agree to

a) appeal on maintainer's responsibility. I cannot imagine anyone
endorses a particular init system by deliberately excluding users of
other systems unless that would be really necessary for proper operation
and thus leaving no choice but doing so. Why do you think we need more
regulation for best practices that are known to work in Debian already?
We trust developers a lot for a reason.

b) it appears that the current "default init system(tm)" is a superset
of other available alternatives, with the lowest common multiple being
sysvinit style scripts, which are supported by all packages that are
providing such start-up scripts, and will continue to do so.

In practice choice 3 allows developers to take advantage of special
features available by the "default init system(tm)" as a last resort
when this is required by the package for proper operation. Yes, choice 3
would also allow the use of "non-default init system(tm)" exclusive
features when no alternative way to achieve the same exists with the
"default init system(tm)", but really, what could that be, in practice?


--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D


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

Re: REISSUED CfV: General Resolution: Init system coupling

Lucas Nussbaum-4
On 09/11/14 at 14:42 +0100, Arno Töll wrote:

> Hi,
>
> On 09.11.2014 13:36, Lucas Nussbaum wrote:
> > With Choice 3, a package maintainer can decide to support only an init
> > system that isn't the default if the maintainer considers it a
> > prerequisite for its proper operation and no patches
> > or other derived works exist in order to support other init systems
> > in such a way to render software usable to the same extent.
>
> Yes. That being said, that's a hypothetical point you're making as we
> (hopefully) all agree to
>
> a) appeal on maintainer's responsibility. I cannot imagine anyone
> endorses a particular init system by deliberately excluding users of
> other systems unless that would be really necessary for proper operation
> and thus leaving no choice but doing so. Why do you think we need more
> regulation for best practices that are known to work in Debian already?
> We trust developers a lot for a reason.
"Proper operation" is not defined in the GR. What if other init systems
provided degraded operation, resulting in bug reports from their users?
We have had scenarios in Debian where maintainers, tired of receiving
bug reports about problems on a specific architecture, decided to drop
support for that architecture from their packages.
Also, not "usable to the same extent" in the sufficient condition for
the maintainer to drop support.

> b) it appears that the current "default init system(tm)" is a superset
> of other available alternatives, with the lowest common multiple being
> sysvinit style scripts, which are supported by all packages that are
> providing such start-up scripts, and will continue to do so.

Not really. Some init systems (at least systemd and upstart) provide
advanced features that are not available in any other init systems.  If
this proposal passes, I think that it would be fairly reasonable for
upstreams or maintainers to start making more advanced uses of systemd
service files, and at the same time, remove init scripts when it's not
possible to alter them to match systemd service files functionality.

> In practice choice 3 allows developers to take advantage of special
> features available by the "default init system(tm)" as a last resort
> when this is required by the package for proper operation. Yes, choice 3
> would also allow the use of "non-default init system(tm)" exclusive
> features when no alternative way to achieve the same exists with the
> "default init system(tm)", but really, what could that be, in practice?

I agree that, in practice, the scenario of a package starting to require
upstart-specific socket activation is unlikely. But given that we are
having a GR about this, I think that it's important to not just think
about the current state of things, but also look further about what it
would mean in the more distant future.

Lucas

signature.asc (828 bytes) Download Attachment
123