Re: Proposal to overturn init systems premature GR

[Thomas Goirand]

On 12/3/19 6:40 PM, Gunnar Wolf wrote:
> However, stating
> the discusion started less than a month ago... Is quite far from the
> observed fact that it started no less than five years ago.

Gunnar,

I very much disagree with this view.

On 12/3/19 6:40 PM, Gunnar Wolf wrote:
> And if something is missing, as others
> have stated, either a high rank for FD or a new GR following this one
> can be the next possible action.

Which would better be avoided. That'd be really bad compared to a few
more days delay to have a correct GR to begin with.

Ian, I support you, I don't think we need to rush. Even if this vote was
postponed until January, it's my view that it would be fine (but I
understand others who think differently).

Thomas Goirand (zigo)

Re: Proposal to overturn init systems premature GR

[Scott Kitterman]

On Tuesday, December 3, 2019 12:13:03 PM EST Sam Hartman wrote:
> I note that our voting system does have recourse for people who believe
> that the vote is called to early.
> 
> They can vote FD above other options.
> And in this specific case, voting G>FD> other options
> would send a clear message that we should develop options based on G.

I don't have a strong opinion on the outcome of the vote, but I do have a 
strong opinion about this.

I think short circuiting the discussion process casts into question the 
legitimacy of the process.

I think you are wrong here.  How can one know where to rank option G when it's 
clearly incomplete.  I don't know if I like it or not.  Let's finish the work 
on getting the ballot right and then vote.

If you think this discussion has been fun, consider the fun of doing it over 
again next year with accusations of DPL bad faith thrown in.

Please wait.

Scott K

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

Re: Proposal to overturn init systems premature GR

[Holger Levsen]

On Tue, Dec 03, 2019 at 11:34:40PM +0200, Wouter Verhelst wrote:
> The issue has existed since five years ago. However, discussion on
> *this* GR has started only a month ago.
> 
> A month is fairly short in Debian time to draft all the options on a
> ballot that is likely to be so contentions. That we've managed to get
> this far is amazing, but does not negate the fact that people are still
> working on their draft.
> 
> If this option does not make progress in a few days, then yes, you're
> right. But I agree with Ian -- even if I'm unlikely to vote for that
> option -- that allowing it a fair chance to arrive onto the ballot is
> important.
[...] 
> I don't think that waiting a few more days is going to make the sky
> fall. There have been votes that took *far* longer than this one to be
> decided on.
> 
> Historically, we've waited until discussion died before we called for
> vote. It feels wrong to not do the same now, on an issue that is likely
> to be this contentious.

I have to somewhat correct my last mail and agree with Wouter here too.

Even though the discussion partly has become somewhat painful again, it's
important to let people finish drafting their options until they are ready
and then vote. Especially after 5 years.

Some holiday dates (which affect everyone differently anyway, just like
weather) shouldn't influence our voting dates too much.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Call for Votes on the Initit Systems GR

[Kurt Roeckx]

On Tue, Dec 03, 2019 at 10:09:26AM -0500, Sam Hartman wrote:
> 
> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.
> As the DPL, I ask the secretary to extend the voting period by a week.

So I will most likely start the vote the 7th at 0 UTC, making the
end time the 27th at 23:59:59 UTC.

I will try to make the ballot tomorrow.


Kurt

Re: Call for Votes on the Initit Systems GR

[Micha Lenk]

Hi all,

just because there are some voices complaining about Sam's call for vote, I 
feel the need to raise my otherwise more silent voice. All in all I concur with 
Sam's assessment that all options are covered well enough to form opinions. Now 
let's vote and see where we are today. And it's not like we can't evolve in the 
future from where we are today.

Regards,
Micha

Re: Reframing

[gregor herrmann]

On Tue, 03 Dec 2019 12:54:40 +, Ian Jackson wrote:

> I have written this mail To people who seconded Guillem's proposal and
> to some people from the thread.  I would particularly like to hear
> your views.
> 
> I am considering making a formal variant of Guillem's proposal, which,
> if Guillem doesn't agree that specific guidance is needed, would stand
> on the ballot alongside Guillem's and my proposal D.  I would like
> that proposal to reflect the views of people who seconded Guillem's
> proposal.

I found and find Guillem's text very appealing; and I also can see
that people who are involved in the issue on the technical or the
policy side would like to have concrete answers to the pending
questions and guidance for moving forward. For the latter I think
that your proposal is a good approach as it tries to spell out the
compromise in concrete actions.

So yes, for me a combination of options G and D would be (or maybe
more accurately: would have been …) helpful in finalizing my ranking
of the options given my ambivalence.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Dave Brubeck: In Your Own Sweet Way


signature.asc
Description: Digital Signature

Re: Proposal to overturn init systems premature GR

[Wouter Verhelst]

On Tue, Dec 03, 2019 at 11:40:15AM -0600, Gunnar Wolf wrote:
> [ Removing tons and tons of personal Cc:s, I guess they all follow d-vote ]
> 
> Ian Jackson dijo [Tue, Dec 03, 2019 at 04:15:02PM +]:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > I have been proposing that there should be an alternative to Guillem's
> > proposal.  I need a few more days to do this.  (Guillem's proposal has
> > IMO excellent framing but lacks suitable specific guidance.  I hope we
> > can make a version which combines Guillem's framing with some
> > appropriate specific guidance, perhaps taken from one of the other
> > proposals.)
> > 
> > Sam has decided to cut short this process.  We started this public
> > discussion less than a month ago.  This is very short.
> > (...)
> 
> Ian, please don't.
> 
> Well, you did. But I must say, I'm not the least thrilled at seeing
> this initiative.
> 
> While I share Sam's impression that the whole discussion has been
> (impressively!) very civil and productive, I do not think further
> delaying will be beneficial to the project. Yes, Guillem's proposal
> arrived quite late in the process, presenting a very different and
> important view. Yes, probably it could be improved. However, stating
> the discusion started less than a month ago... Is quite far from the
> observed fact that it started no less than five years ago.

No, that's not true.

The issue has existed since five years ago. However, discussion on
*this* GR has started only a month ago.

A month is fairly short in Debian time to draft all the options on a
ballot that is likely to be so contentions. That we've managed to get
this far is amazing, but does not negate the fact that people are still
working on their draft.

If this option does not make progress in a few days, then yes, you're
right. But I agree with Ian -- even if I'm unlikely to vote for that
option -- that allowing it a fair chance to arrive onto the ballot is
important.

> We are trying to put closure to it. I think we can improve minutiae
> forever, but will never reach a perfect solution that leaves everybody
> happy.

Perhaps, but the only way to do that is to allow every valid option to
reach the ballot.

I don't think that waiting a few more days is going to make the sky
fall. There have been votes that took *far* longer than this one to be
decided on.

Historically, we've waited until discussion died before we called for
vote. It feels wrong to not do the same now, on an issue that is likely
to be this contentious.

> That's the main reason to hold a GR. The available options
> (Guillem's included) will most probably cover the opinions / feelings
> of basically all developers. And if something is missing, as others
> have stated, either a high rank for FD or a new GR following this one
> can be the next possible action.

So you're saying that instead of extending things for a few days now,
you'd rather see the process started over again, which will take a *lot*
longer than that?

That seems... weird.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Call for Votes on the Initit Systems GR

[Wouter Verhelst]

Hi Sam,

On Tue, Dec 03, 2019 at 10:09:26AM -0500, Sam Hartman wrote:
> 
> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.
> As the DPL, I ask the secretary to extend the voting period by a week.

This is the first time in the history of the project[1] that a call for
vote is done *while people are still actively drafting options*. Usually
we wait for discussion to die out before we call for votes.

Even if that isn't the process set out in the constitution, it feels
very disingenious and dishonest to not allow people to finalize their
options. It is a break with precedent, and one that I think is not
necessary.

The sky isn't going to fall, and the world isn't going to end, if we
postpone this a bit more. Even if you don't want this to be voted on
over the holidays, you can still postpone it so that the vote happens
*after* the holidays.

Please don't make a bad situation worse.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Proposal to overturn init systems premature GR

[Holger Levsen]

On Tue, Dec 03, 2019 at 05:40:57PM +0100, Enrico Zini wrote:
> I feel that the air in -vote has been getting very heavy in the last day
> or so, and I was quite happy that Sam opted to cut the pain short and go
> for a vote.

I (mostly) missed this part busy preparing an event...

> I agree that all the useful options seem to be on the ballot, and I look
> forward to see what comes out. I would prefer that we didn't start
> something that looks like meta-discussing options, and meta-discussing
> whether to meta-discuss options, and so on.
> 
> Nitpicking on the constitutional process like this looks to me like an
> interesting move in some competitive board game. I would prefer to see
> less competition, and more cooperative focus on trying to make Policy
> unstuck while trying to keep pain to a minimum.

   _ 
   _  / |
 _| |_| |
|_   _| |
  |_| |_|

(+1)

IOW, a GR to overturn the GR to delay the GR about the GR is...

then, I also think all the useful options are on the table, but if Ian 
has something to greatly improve option G, the latest of the available options,
very soon, I can see how we can still start voting on the 8th or 10th or 
12th or whatever. Everybody who is interested to vote on this GR, and can
vote, will know about this GR and so either can vote early and enjoy the
holidays or enjoy the holidays, read as much background info as wanted
during/after and before the holidays and then vote. (or whenever this vote ends)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Mike Gabriel]

Hi Ian,

On  Di 03 Dez 2019 13:54:40 CET, Ian Jackson wrote:


* Should I adopt Guillem's framing as a preamble to my own proposal ?
  (Should this be a new alternative or a replacement?)

* Would Guillem's framing make a good preamble to Dmitry's option ?

* Or do the supporters of Guillem's option favour some other
  combination of possible answers to the specific questions ?


Personally, I think that the full scope of the tendency spectrum  
regarding init systems is +/- covered by the available proposals.


However, not all proposals provide proper guidance how to act and  
react in certain corner and/or non-corner cases.


I think, this lack of specifics can be amended with a follow-GR that  
goes into details and fine-tunes the voted for proposal.


Personally, I am much more on the multiple init systems side than on  
the systemd side, however, if the majority in Debian wants to see  
systemd-only, you can safe the drafting time today for other valuable  
tasks.


My 2¢,

light+love
Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpyIX_aSZYC3.pgp
Description: Digitale PGP-Signatur

Re: Proposal to overturn init systems premature GR

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Russ Allbery (2019-12-03 19:19:50)

>> Does anyone truly believe that another round of wordsmithing or changes
>> to statements of principles will change a lot of opinions or votes this
>> deep into this discussion?

> Evidently someone truly believes there is need for another round.

I probably didn't express this well enough, but the reason why I was using
the phrasing that I did was to ask Ian and Matthew to think about whether
the work that they were planning on doing is as important as it seemed at
first glance.

Maybe they'll think about it some more and conclude that indeed it is and
I'm wrong.  But it's easy to get caught up in a plan and then to feel
frustrated and treated poorly when that plan is derailed, even though
that's not quite the same as being relatively certain that the work was
important and needed to happen as planned.

-- 
Russ Allbery (r...@debian.org)  

Re: Proposal to overturn init systems premature GR

[Russ Allbery]

Sean Whitton  writes:

> Russ, could you chime in here -- do you still think that starting on the
> 8th would give enough time to people who might be away from the PGP keys
> during the holiday season, or would we be cutting it tight?

> (I am almost never away from my own PGP subkeys so I don't feel I can
> judge myself whether it would be enough time.)

I also am never away from my PGP subkeys, so I can't speak from personal
experience.  I believe that starting on the 8th would probably be okay,
though.

That said, I'm also rather dubious that anything is going to fundamentally
change in the next few days.  Ian already has an excellent,
well-thought-out proposal on the ballot that reflects his position.  The
available solution space seems well-covered by the options available.
It's getting harder to keep the discussion productive.

Does anyone truly believe that another round of wordsmithing or changes to
statements of principles will change a lot of opinions or votes this deep
into this discussion?  To me at least it feels like everyone has had a
say, all the ballot proposals that were fielded within a week or so of
when the GR was originally proposed have been refined and are
well-represented, all of the major constituencies seem to be represented
on the ballot, and we've reached the point of diminishing returns.

Maybe I'm wrong.  I have my own bias towards making a decision and I'm
also dubious about the merits of high-level statements of principle, so I
probably have a skewed perspective.  If people feel like their vote and
the outcome are truly likely to change based on further work on ballot
options, by all means second or otherwise indicate support for Ian's
request for delay and I guess we can all figure out what to do with that
information.  Personally, I'm reasonably certain that nothing that could
happen over the next four or five days would change my vote.

-- 
Russ Allbery (r...@debian.org)  

Re: Proposal to overturn init systems premature GR

[Gunnar Wolf]

[ Removing tons and tons of personal Cc:s, I guess they all follow d-vote ]

Ian Jackson dijo [Tue, Dec 03, 2019 at 04:15:02PM +]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I have been proposing that there should be an alternative to Guillem's
> proposal.  I need a few more days to do this.  (Guillem's proposal has
> IMO excellent framing but lacks suitable specific guidance.  I hope we
> can make a version which combines Guillem's framing with some
> appropriate specific guidance, perhaps taken from one of the other
> proposals.)
> 
> Sam has decided to cut short this process.  We started this public
> discussion less than a month ago.  This is very short.
> (...)

Ian, please don't.

Well, you did. But I must say, I'm not the least thrilled at seeing
this initiative.

While I share Sam's impression that the whole discussion has been
(impressively!) very civil and productive, I do not think further
delaying will be beneficial to the project. Yes, Guillem's proposal
arrived quite late in the process, presenting a very different and
important view. Yes, probably it could be improved. However, stating
the discusion started less than a month ago... Is quite far from the
observed fact that it started no less than five years ago. We are
trying to put closure to it. I think we can improve minutiae forever,
but will never reach a perfect solution that leaves everybody
happy. That's the main reason to hold a GR. The available options
(Guillem's included) will most probably cover the opinions / feelings
of basically all developers. And if something is missing, as others
have stated, either a high rank for FD or a new GR following this one
can be the next possible action.


signature.asc
Description: PGP signature

Re: Proposal to overturn init systems premature GR

[Matthew Vernon]

Sam Hartman  writes:

> I note that our voting system does have recourse for people who believe
> that the vote is called to early.
>
> They can vote FD above other options.
> And in this specific case, voting G>FD> other options
> would send a clear message that we should develop options based on G.

This is true, but unhelpful - it would obviously be a "nuclear" option,
so I suspect that even people who think that will be reluctant to
restart this entire discussion all over again.

The right answer is to give people another couple of days to get the
last option sorted out. That doesn't stop everyone being able to vote in
good time, and is obviously fair to everyone.

Regards,

Matthew

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

Re: Proposal: Focus on systemd

[Sean Whitton]

Hello,

On Sun 01 Dec 2019 at 11:06AM +02, Martin Michlmayr wrote:

> I'm sorry for the delay.  Maybe this reply is moot now that proposal C
> has been withdrawn but I wanted to share my personal view of why
> another proposal was needed.
>
> [...]
>
> Like I said, proposals B and D have a lot of values that you can agree
> with.  Proposal C doesn't have any what I originally described as
> "passion".  When talking to other people I realized that proposal C
> lacks "vision".  Proposals B/D have much more of that
> passion/values/vision.
>
> So looking at the proposals, I just found the offering a bit skewed
> because I felt that the proposal that a lot of people want has no
> "sway" in comparison with some of the other proposals.
>
> I hope that explains it.

It does -- thanks, to you and to the others who responded to my
question.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Proposal to overturn init systems premature GR

[Sam Hartman]

I note that our voting system does have recourse for people who believe
that the vote is called to early.

They can vote FD above other options.
And in this specific case, voting G>FD> other options
would send a clear message that we should develop options based on G.

Re: Proposal to overturn init systems premature GR

[Kurt Roeckx]

On Tue, Dec 03, 2019 at 04:46:12PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Proposal to overturn init systems premature GR"):
> > On Tue, Dec 03, 2019 at 04:15:02PM +, Ian Jackson wrote:
> > > I hereby propose the following General Resolution:
> > > 
> > >  Title: A few extra days for init systems GR text drafting
> > > 
> > >  1. We exercise the DPL's power to set the minimum discussion
> > > period for the init systems GR to end at 23:59 UTC on
> > > Friday the 6th of December.  (Constitution 4.1(3).)
> > 
> > It would have been better that you did this before he called for
> > vote. There was clearly enough time to do this, and he's been
> > clear that he would do the CFV today.
> 
> I had not appreciated that.  It may have been buried in one of the
> mails.
> 
> > >  5. All of the decisions in (2), (3) and (4) above, where applicable,
> > > are immediately put on hold (Constitution 4.2(2)(2) or 4.2(2)(3),
> > > as applicable.)
> > > 
> > >  6. This entire GR proposal is withdrawn if the DPL:
> > >   (i) withdraws the Call for Votes;
> > >   (ii) adjusts the minimum discussion period according
> > >to our (1), above; and
> > >   (ii) commits to not reducing it again and/or calling
> > >for a vote without giving 24 hours' notice.
> > > 
> > > I think this is effective if I get 5 or 10 seconders, depending on the
> > > Secretary's interpretation of the Constitution.
> > 
> > 5) asks the DPL's decision to be put on hold, so that part would
> > require 2K. But I think it's too late for that.
> 
> Are you saying my proposal is ineffective even if I get 2K
> seconds ?

Currently, I think it is. But I'm still open to let people
convince me otherwise. So the options I currently see is:
- That someone convices me that you can still overturn his decision
  to change the discussion period after he called for vote. In
  theory he could change the discussion period and call for vote at
  the same time, and in that case I would clearly allow it, but
  I'm not sure where the line is between allowing it and not.
- That someone convices that amendements that received enough
  sponsors reset reset the discussion period.

> I would like to point out that I asked you for advice about this on
> the 20th of November.  Specifically, I asked
>   Supposing Sam calls for a vote, can I stop him ?
> and then wrote
>   I think maybe I can do this:
> and then gave a summary of roughly what my (4) and (5) do.
> You didn't reply.

I'm sorry, I missed that mail.


Kurt

Re: Proposal to overturn init systems premature GR

[Ian Jackson]

Enrico Zini writes ("Re: Proposal to overturn init systems premature GR"):
> I agree that all the useful options seem to be on the ballot, and I look
> forward to see what comes out. I would prefer that we didn't start
> something that looks like meta-discussing options, and meta-discussing
> whether to meta-discuss options, and so on.

I have a concrete option that I am still working on and can propose in
the next 24-48h, based on Guillem's text.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Proposal to overturn init systems premature GR

[Ian Jackson]

Kurt Roeckx writes ("Re: Proposal to overturn init systems premature GR"):
> On Tue, Dec 03, 2019 at 04:15:02PM +, Ian Jackson wrote:
> > I hereby propose the following General Resolution:
> > 
> >  Title: A few extra days for init systems GR text drafting
> > 
> >  1. We exercise the DPL's power to set the minimum discussion
> > period for the init systems GR to end at 23:59 UTC on
> > Friday the 6th of December.  (Constitution 4.1(3).)
> 
> It would have been better that you did this before he called for
> vote. There was clearly enough time to do this, and he's been
> clear that he would do the CFV today.

I had not appreciated that.  It may have been buried in one of the
mails.

> >  5. All of the decisions in (2), (3) and (4) above, where applicable,
> > are immediately put on hold (Constitution 4.2(2)(2) or 4.2(2)(3),
> > as applicable.)
> > 
> >  6. This entire GR proposal is withdrawn if the DPL:
> >   (i) withdraws the Call for Votes;
> >   (ii) adjusts the minimum discussion period according
> >to our (1), above; and
> >   (ii) commits to not reducing it again and/or calling
> >for a vote without giving 24 hours' notice.
> > 
> > I think this is effective if I get 5 or 10 seconders, depending on the
> > Secretary's interpretation of the Constitution.
> 
> 5) asks the DPL's decision to be put on hold, so that part would
> require 2K. But I think it's too late for that.

Are you saying my proposal is ineffective even if I get 2K
seconds ?


I would like to point out that I asked you for advice about this on
the 20th of November.  Specifically, I asked
  Supposing Sam calls for a vote, can I stop him ?
and then wrote
  I think maybe I can do this:
and then gave a summary of roughly what my (4) and (5) do.
You didn't reply.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Proposal to overturn init systems premature GR

[Kurt Roeckx]

On Tue, Dec 03, 2019 at 04:15:02PM +, Ian Jackson wrote:
> I hereby propose the following General Resolution:
> 
>  Title: A few extra days for init systems GR text drafting
> 
>  1. We exercise the DPL's power to set the minimum discussion
> period for the init systems GR to end at 23:59 UTC on
> Friday the 6th of December.  (Constitution 4.1(3).)

It would have been better that you did this before he called for
vote. There was clearly enough time to do this, and he's been
clear that he would do the CFV today.

>  2. The DPL's decision to call for a vote on the init systems GR
> is overturned.  (Constitution 4.1(3).)

It's not because he happens to be DPL, that I think this clause
should apply to the CFV.

>  3. Additionally, if the DPL's decision to call for a vote is enabled
> by a decision by the DPL to vary the minimum discussion period:
> the DPL's decision to vary the minimum discussion period is
> overturned.

It would have been better that you did this before the CFV.

>  4. If the decision to call for a vote cannot be overturned via
> Constitution 4.1(3), the DPL's decision(s) to propose all the
> DPL's options on the ballot(s) is overturned.  We believe the
> effect of this is to either stop the process so that it must be
> restarted, or to drop the DPL's options from the ballot so that
> the DPL no longer has standing to call for a vote.  (We would
> prefer the latter, if we can't have what we want in (1) and (2),
> above.)

If you're not happy with the result of the GR, you can have a
whole new GR.

>  5. All of the decisions in (2), (3) and (4) above, where applicable,
> are immediately put on hold (Constitution 4.2(2)(2) or 4.2(2)(3),
> as applicable.)
> 
>  6. This entire GR proposal is withdrawn if the DPL:
>   (i) withdraws the Call for Votes;
>   (ii) adjusts the minimum discussion period according
>to our (1), above; and
>   (ii) commits to not reducing it again and/or calling
>for a vote without giving 24 hours' notice.
> 
> I think this is effective if I get 5 or 10 seconders, depending on the
> Secretary's interpretation of the Constitution.

5) asks the DPL's decision to be put on hold, so that part would
require 2K. But I think it's too late for that.


Kurt

Re: Proposal to overturn init systems premature GR

[Enrico Zini]

On Tue, Dec 03, 2019 at 04:15:02PM +, Ian Jackson wrote:

> I think we can use the constitutional process to delay this, to make

I feel that the air in -vote has been getting very heavy in the last day
or so, and I was quite happy that Sam opted to cut the pain short and go
for a vote.

I agree that all the useful options seem to be on the ballot, and I look
forward to see what comes out. I would prefer that we didn't start
something that looks like meta-discussing options, and meta-discussing
whether to meta-discuss options, and so on.

Nitpicking on the constitutional process like this looks to me like an
interesting move in some competitive board game. I would prefer to see
less competition, and more cooperative focus on trying to make Policy
unstuck while trying to keep pain to a minimum.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Proposal to overturn init systems premature GR

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian>  2. The DPL's decision to call for a vote on the init systems
Ian> GR is overturned.  (Constitution 4.1(3).)

This was not a DPL decision.
This was a decision of an author of a proposal on the ballot.
So I don't think this is a decision that can be overturned under 4.1
(3).


For those considering how to respond in thinking about whether to
overturn or put on hold my decision to change the minimum discussion
period.
Please note that what I effectively did is make it so that all
amendments are treated the same.

Under Ian's constitution, amendments proposed by the author of the GR
reset the discussion clock, but other changes to the amendments do not.
I used the DPL's powers to make sure that we had a consistent playing
field by making it so that like the other authors of proposals on the
ballot, I was able to accept amendments without delaying the process.


signature.asc
Description: PGP signature

Re: Proposal to overturn init systems premature GR

[Ian Jackson]

Sean Whitton writes ("Re: Proposal to overturn init systems premature GR"):
> On Tue 03 Dec 2019 at 04:15PM +00, Ian Jackson wrote:
> > We can do this with enough time to vote before Christmas, as Russ
> > reasonably points out is desirable.  Russ suggested a voting period
> > starting on the 8th of December would be the latest sensible [2],
> > which probably means a call for votes the previous day.
> 
> Russ, could you chime in here -- do you still think that starting on the
> 8th would give enough time to people who might be away from the PGP keys
> during the holiday season, or would we be cutting it tight?
> 
> (I am almost never away from my own PGP subkeys so I don't feel I can
> judge myself whether it would be enough time.)

I could live with a shorter timescale if I had at least 24h and
preferably 48h notice.

I do think that it should have been obvious that this public
discussion ought to have been done in a more relaxed way.  Extra time
does not increase the pain much.  The public discussion should have
started a month ago, or in January.  But we are here now and trying to
postpone it over Christmas in the middle of it is a bad idea.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Call for Votes on the Initit Systems GR

[Matthew Vernon]

Sam Hartman  writes:

> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.

I think this is an error, and urge you to reconsider; there is clearly
an active process to try and refine one of the options on the ballot
paper. The vote call could wait 'til the weekend and still achieve the
objective of giving people time to vote before the holiday period
arrives. 

> I appreciate that Ian wishes to have an opportunity to explore other
> things based on option G.
> In other circumstances, I might have had a hard decision about whether
> to wait longer to let that discussion progress.
>
> Today, though, Ian's message is contributing to the souring tone of the
> discussion.

In particular, you give the very unfortunate impression that calling the
CFV now while Ian and Guillem are still refining the proposal Guillem
wrote is being done to in effect punish Ian for his use of language.

Please, please reconsider: this is an important vote on a complex and
challenging issue that many people in Debian feel strongly about - it's
vital that we get as good a set of options on the ballot as possible. I
know there is a concern about letting people vote before Christmas, but
that aim is still coherent with letting the option drafting finish.

Regards,

Matthew

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

Re: Proposal to overturn init systems premature GR

[Sean Whitton]

Hello,

On Tue 03 Dec 2019 at 04:15PM +00, Ian Jackson wrote:

> We can do this with enough time to vote before Christmas, as Russ
> reasonably points out is desirable.  Russ suggested a voting period
> starting on the 8th of December would be the latest sensible [2],
> which probably means a call for votes the previous day.

Russ, could you chime in here -- do you still think that starting on the
8th would give enough time to people who might be away from the PGP keys
during the holiday season, or would we be cutting it tight?

(I am almost never away from my own PGP subkeys so I don't feel I can
judge myself whether it would be enough time.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Call for Votes on the Initit Systems GR

[Sam Hartman]

It was pointed out to me off-list that the constitution  says that in
calling for a vote I am supposed to say what I think the options are.
That feels kind of presumptuous given the work the secretary has done.
Kurt and I discussed off list much earlier and he doesn't need me to say
what I think the ballot options are.
But for the avoidance of doubt,
As of the time of this message, I believe that Proposals  F, B, A, D, E,
and G from
https://www.debian.org/vote/2019/vote_002

represent what we've discussed as a ballot.
I did not re-read each proposal today, but I did read them Sunday.

--Sam


signature.asc
Description: PGP signature

Proposal to overturn init systems premature GR

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have been proposing that there should be an alternative to Guillem's
proposal.  I need a few more days to do this.  (Guillem's proposal has
IMO excellent framing but lacks suitable specific guidance.  I hope we
can make a version which combines Guillem's framing with some
appropriate specific guidance, perhaps taken from one of the other
proposals.)

Sam has decided to cut short this process.  We started this public
discussion less than a month ago.  This is very short.

I think we can use the constitutional process to delay this, to make
sure the options on this important ballot reflect the range of views
within the project, so people can vote for options that accurately
reflect their opinions.

We can do this with enough time to vote before Christmas, as Russ
reasonably points out is desirable.  Russ suggested a voting period
starting on the 8th of December would be the latest sensible [2],
which probably means a call for votes the previous day.

I hereby propose the following General Resolution:

 Title: A few extra days for init systems GR text drafting

 1. We exercise the DPL's power to set the minimum discussion
period for the init systems GR to end at 23:59 UTC on
Friday the 6th of December.  (Constitution 4.1(3).)

 2. The DPL's decision to call for a vote on the init systems GR
is overturned.  (Constitution 4.1(3).)

 3. Additionally, if the DPL's decision to call for a vote is enabled
by a decision by the DPL to vary the minimum discussion period:
the DPL's decision to vary the minimum discussion period is
overturned.

 4. If the decision to call for a vote cannot be overturned via
Constitution 4.1(3), the DPL's decision(s) to propose all the
DPL's options on the ballot(s) is overturned.  We believe the
effect of this is to either stop the process so that it must be
restarted, or to drop the DPL's options from the ballot so that
the DPL no longer has standing to call for a vote.  (We would
prefer the latter, if we can't have what we want in (1) and (2),
above.)

 5. All of the decisions in (2), (3) and (4) above, where applicable,
are immediately put on hold (Constitution 4.2(2)(2) or 4.2(2)(3),
as applicable.)

 6. This entire GR proposal is withdrawn if the DPL:
  (i) withdraws the Call for Votes;
  (ii) adjusts the minimum discussion period according
   to our (1), above; and
  (ii) commits to not reducing it again and/or calling
   for a vote without giving 24 hours' notice.

I think this is effective if I get 5 or 10 seconders, depending on the
Secretary's interpretation of the Constitution.

Ian.

[1] Russ's mail about timing
  https://lists.debian.org/debian-vote/2019/11/msg00184.html
-BEGIN PGP SIGNATURE-

iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3mie8gHGlqYWNrc29u
QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTnc+wf9FHcAvA8MSs9o
4gQGk1Xxj1L0ds1SaKEFFphoKxu0qbadTuEzUXQq8Iy3gaOrCRXEVEnUDCmJeoEo
eJtFuXRXC3T6Qa1ZydVnuBUujdq+dIDmD06VoJLsbxF+xO8AJm7Pi0tHNaddCjZ9
E2WgA5b1d14+f5SsJe1Qz72UMMRUtLKCNj/I4uEYCZgjbTElJy2pa3mUEShNh1uC
D7u9N3Su2DPVfrPWJ6WOWe0NR5PsAtdrPheSmZ5fkvXUqQRDgYgewwc7dV/+p27Z
D8H5NYFiU3KEhgI/thp95tyL4k5Y/2+HCtbPvDMCaSbuvGlRPxsR5I7uaV9L33d9
4iWt4pdJxg==
=VL1t
-END PGP SIGNATURE-

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Call for Votes on the Initit Systems GR

[Sam Hartman]

The minimum discussion period lapsed sometime Saturday.
So, as one of the authors of a proposal, I ask the secretary to please
prepare a ballot and start the vote.
As the DPL, I ask the secretary to extend the voting period by a week.


I think we've gotten to a point where the existing proposals are in
forms that their authors are happy with.  Guillem got a chance to author
his proposal and to respond to the comments he received.  My reading of
his message is he's happy with where things stand.

This discussion has been really great so far.  However, over the last
day, the tone has been turning kind of nasty.  We've been sniping at
each other more.
I think there are two contributing factors to that:

First, this has been a long process.  We've put in a lot of energy, and
I think some of us are coming to a point where that is rubbing us a bit
raw.

Secondly, discussions run through a progression.  In the beginning, you
get the most dedicated people who are currently available.  The people
who care enough to make sure they are there.  Then as the discussion
progresses, you get more people involved.  Each round of new people has
a cost.  You have to revisit things, help catch them up, sometimes
reconsider significant chunks of what you have already thought in light
of comments they make.  The first couple times this happens, we call it
additional review from a wider audience.  It's essential for doing a
good job.

Each successive round of people drifting in has a higher cost.
Typically each successive round of people wondering in are willing to
dedicate less energy, and have less context in what has come before.
Some of the costs grow higher.  They are more likely to bring up things
that are well settled without new insight.  The earlier participants
know where some of the pain points are, and are more likely to know
where to be careful in what they say to be respectful.  After a certain
point, the people drifting in might have apparently really simple ideas
that are unworkable because they disregard the needs of some segment of
the community.  Hearing these again and again can be harmful.

I think both factors are contributing.

So, I think we've accomplished what we can accomplish here in this
discussion.
Continuing the discussion would simply escalate tensions for all of us
and I don't think has any probability of significantly increasing the
ballot.

For those who want a statement of principles on the multiple init
systems side, we have option D.  For those who want it on the systemd
side we have option F.
There are some interesting things in option G.
I wouldn't be surprised if independent of this GR, people explore
whether those options can have some value in our project.
Those who believe that the project should not be deciding on specifics,
but somehow we should take the statements in G and move forward can vote
that way.

I appreciate that Ian wishes to have an opportunity to explore other
things based on option G.
In other circumstances, I might have had a hard decision about whether
to wait longer to let that discussion progress.

Today, though, Ian's message is contributing to the souring tone of the
discussion.

> All other options [1]
>Lack of an init script is a normal or wishlist bug and
>maintainers can block them because they want systemd
hegemony.

Systemd hegemony is just as loaded as the statements several of us were
complaining about last night.

Similarly:
>Everyone is allowed to use them willy-nilly and non-systemd
>support will rot.

And again:
>Theoretical degradations of dependencies on systemd
>systems

The mail is actually more disrespectful than that.  Ian, who has an
excellent command of English rhetoric effectively uses his desire to
talk about option G as a reason to summarize what he sees the key
questions are.  But then he chooses to answer these key questions, and
rather than using language respectful to the idea that viewpoints on
these differ wildly, he uses the reasonable measured language of fact
to describe the options he prefers.  Then when describing other
options, he continues to use the language of fact, rather than
language that admits to other opinions and acknowledges that much of
this is his opinion.

I know I've warned Ian about this pattern during this discussion.
I know others have talked to Ian about similar issues over the years.

So, even Ian is contributing to a pattern of disrespectful discourse.
I think we've accomplished what we have set out to accomplish: I think we have 
a very good ballot.
Any future refinements come at what I believe is too high of a cost.

So I call for votes.

--Sam


signature.asc
Description: PGP signature

Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Ian Jackson]

In some sense I am asking the same questions as Russ.

Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to 
support portability and multiple implementations)"):
> I've to say, that while I think I understand where your and other similar
> reactions to this proposal are coming from, I also found them a bit
> perplexing. :)

Let me skip to the end:

> The key here, I guess, is that each situation needs to be evaluated
> independently, and no magic decision tree will ever fix trying to work
> things out with other people, in good faith, and trying to find
> solutions or compromises that satisfy others and us too. But maybe this
> is asking too much, dunno. :/
> 
> I understand that not giving apparently detailed guidance might make
> things more difficult for the policy editors, and I'm sorry about that,
> but I think no one ever expected that collaborating in a project such as
> Debian with people pulling in random directions would always be easy?

As you know I very much agree with you about the framing.

But it appears that you don't that we should then, in something like
your proposal, take the principles in that framing and apply them in
to some of the most contentious specific problems facing us today.

In its current state I think your proposal is unlikely to do well.
I am very keen that something with your framing text should do well.

Since you don't seem to agree that your option should be supplemented
by specifics, I would like to ask the rest of the community:

* Should I adopt Guillem's framing as a preamble to my own proposal ?
  (Should this be a new alternative or a replacement?)

* Would Guillem's framing make a good preamble to Dmitry's option ?

* Or do the supporters of Guillem's option favour some other
  combination of possible answers to the specific questions ?

I think they key specific questions are:

Q1 Init scripts.  Possible answers, roughly:

 E  Lack of an init script is an RC bug; maintainers must write
init scripts.

 D  Lack of an init script is not an RC bug but contributions of init
scripts should be filed as RC bugs.  Ie the non-systemd community
must write them but maintainers must accept them.

 All other options [1]
Lack of an init script is a normal or wishlist bug and
maintainers can block them because they want systemd
hegemony.

Q2 sysusers.d, systemd timer units, etc.

 E  May not be used (RC bug) unless a non-systemd-pid-1
implementation is available.  Ie proponents of these
interfaces must write the non-systemd variant.

 D  Can be standardised in policy and used but only if they (i) are
any good (ii) can sensibly exist for non-systemd.  Ie, the
non-systemd community must write the non-systemd variant, but they
will get the time to do so.

 All other options [1]
Everyone is allowed to use them willy-nilly and non-systemd
support will rot.

Q3 dependencies which cause init system switching etc.

 E,D
Forbiddden

 All other options [1]
Allowed.  Theoretical degradations of dependencies on systemd
systems will continue to make it really hard to install and
maintain non-systemd ones.

I have written this mail To people who seconded Guillem's proposal and
to some people from the thread.  I would particularly like to hear
your views.

I am considering making a formal variant of Guillem's proposal, which,
if Guillem doesn't agree that specific guidance is needed, would stand
on the ballot alongside Guillem's and my proposal D.  I would like
that proposal to reflect the views of people who seconded Guillem's
proposal.

Thanks
Ian.

[1] Sam's B "Support for multiple init systems is Important" appears
to allow NMUs to provide init scripts and to use alternatives to
systemd facilities but it says "According to the NMU guidelines".  The
NMU guidelines forbid NMUs when the maintainer has explicitly said
they do not want a particular change.  So in practice a maintainer who
does not want an init script in their package can block this and the
only possible recourse is to the TC, which is not suitable and not
effective.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
 

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Mon, 02 Dec 2019 at 00:28:54 +0100, Simon Richter wrote:
> Wasn't there a plan to add support for containers managed through
> systemd that have filtered access to the system dbus, or is that just a
> special case of a service unit?

As a general rule, "heavyweight" containers with their own init system
that behave like a lighter-weight alternative to VMs (notably lxd and
some uses of systemd-nspawn) have their own set of D-Bus buses managed
by their own init system and process tree, the same as if they were a VM;
while "lightweight" containers that behave more like a chroot (like Docker
and some uses of systemd-nspawn) or a restricted view of the host system
(like most bubblewrap-based containers) either share the host system's
buses, or don't have any D-Bus access at all.

Containers managed as system services by systemd-as-pid-1 are outside
any login session or user-session, so it would not be appropriate for
them to access anyone's session bus. They could access the D-Bus system
bus if desired (with or without filtering). If they access the system
bus, I would expect it to be conceptually the same system bus used by
non-contained system services like NetworkManager, but maybe with fewer
things that they are allowed to do.

Flatpak apps in containers have filtered access to the D-Bus session
and/or system bus from the host system. This is conceptually the same
as if they weren't in a container, but with a firewall-style filter
(xdg-dbus-proxy) between the client and the bus. Not everything is
allowed, but everything that *is* allowed behaves the same as if there
was no container: the same number of buses exist, and their scopes are
the same.

As far as I'm aware, Snap apps are approximately the same shape as Flatpak
in this respect: filtered access to the D-Bus session and/or system
bus from the host system (if you're running Ubuntu's kernel patchset
with AppArmor enhancements), or unfiltered access (otherwise). Again,
this doesn't change the number of buses that exist or what they mean.

smcv


signature.asc
Description: PGP signature

Re: My analysis of the proposals

[Thomas Goirand]

Hi,

I've CC-ed Benda, so he may answer too.

On 12/2/19 12:07 AM, Uoti Urpala wrote:
> As there currently aren't credible alternatives to systemd, not even at
> the level of Upstart, I think it's wrong to phrase the question in
> terms of whether Debian "supports innovation" and so on.

I don't agree. OpenRC is, these days, better than what Upstart was in
many ways. For example, it supports cgroups, it is state-full, and it
has process supervision [1] (all of which Upstart didn't have as a
feature). I cannot agree that OpenRC doesn't bring any innovation. Just
try it, it's easy:

apt-get install openrc sysvinit-core

reboot, and you're done. If you want more, you can replace sysv-init by
openrc-init (beware that the "reboot" command isn't implemented by
default, see the Gentoo doc for that...).

Writing a runscript is as easy as a systemd unit, and the page I link to
shows it's a little bit different, but largely as easy.

What needs to actually happen, IMO, is that sysv-rc dies in the favor of
OpenRC as a replacement, so that we have a way of getting completely rid
of the obsolete part of sysv-rc (ie: slowly replacing sysv-rc init
scripts by declarative runscripts) without loosing anything. Benda, why
don't you do that?

Cheers,

Thomas Goirand (zigo)

[1] https://wiki.gentoo.org/wiki/OpenRC/supervise-daemon

Re: Question Under Proposal D: Compile Time Option

[Thomas Goirand]

Hi Sam,

On 12/2/19 6:12 PM, Sam Hartman wrote:
>> "Thomas" == Thomas Goirand  writes:
> 
> Thomas> Sam,
> 
> Thomas> Is this a real life case (if so, please name the
> Thomas> package...), or just a pure fictional one, just because you
> Thomas> love debating?
> 
> Thomas> Cheers,
> 
> So, first of all, note that this question has already been adequately
> answered:
> * the significant effect on systemd installations criteria is the
> biggest consideration
> *  compiling twice  or turning into runtime configuration are the
> biggest mittigation.
> 
> I had at least two situations in mind: Gnome (say policykit) and
> libvert.
> They are a bit different.
> 
> I think your tone is overly confrontational.

This is a very short sentence, and nothing aggressive in it. Please
re-read with this in mind.

Moving forward, I'll try to re-read what I send, add a smile or
something, so that it becomes more obvious that I don't have bad intention.

> based on several previous messages, it was clear at the time I wrote the
> message that it was a real issue.
> Ian knew that; Simon knew that.

It wasn't for me, and it I'm happy to know more now.

> You come along a couple of days later and imply that I might not have
> been acting in good faith and make Debian just a little less nice to be
> in.

Sam, I haven't done that at all. If that's the perception, sorry for the
bad choice of words.

Cheers,

Thomas Goirand (zigo)

Re: Reframing

[Martin Michlmayr]

* Guillem Jover  [2019-12-02 22:55]:
> The key here, I guess, is that each situation needs to be evaluated
> independently

Guillem, there's a lot of stuff I agree with you on, both in this
email and the proposal you wrote.

What I find strange though is that you acknowledge in this email that
each situation needs to be evaluated independently, but your GR
proposal is a blank statement about portability that completely
ignores that the GR is trying to evaluate only the init system
question.

I support "portability and multiple implementations" where this makes
sense.  People have tried to support multiple init systems but it
hasn't worked out for whatever reason (and you can argue that there was
never a real attempt because various people blocked it, etc, but the
point is that the old approach hasn't worked out and everyone is tired
with the situation).  That's why we've reached the point of this GR to
find a way forward.

With your libaio, GNOME and llvm examples you acknowledge that there
needs to be a cost and benefit analysis for each case, but then when
we have a GR to find out specifically how people see that analysis for
*init systems* you propose an amendment that basically says
"portability at (almost) any cost".

-- 
Martin Michlmayr
https://www.cyrius.com/