Re: Additional CTTE Drafting Meeting useful?

2014-02-08 Thread Steve Langasek
On Wed, Feb 05, 2014 at 05:02:46PM -0800, Don Armstrong wrote:
 Would one more IRC meeting be useful to nail down the ballot options and
 their drafts?

 Our next scheduled meeting is the 27th of February, but we could have
 one on the 13th or earlier at the usual time if that worked for
 everyone.

 I can do the following dates:

snip
 February 14 2014 18:00:00 GMT
snip

I'm not opposed to a realtime drafting session, but the above is the only
one of the proposed times that works for me.

I also think having a drafting session that doesn't have representation of
the full range of opinions from the TC is likely to be counterproductive; it
allows for rapid iteration on ballot options, but to little effect if those
options don't actually have consensus behind them.

So I think on-list drafting is probably best here.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#727708: Additional CTTE Drafting Meeting useful?

2014-02-07 Thread Nikolaus Rath
Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Ansgar Burchardt writes (Re: Additional CTTE Drafting Meeting useful?):
 In this case I suggest to decide just the question of the default init
 system on Linux architectures first and address further details later if
 no consensus can be found elsewhere. Finding the correct wording then
 should be easier.

 I strongly object to this approach for the reasons I have given
 already.

 If I am given the opportunity to do so, if such a resolution is
 proposed I will always propose amendments to settle the T vs L
 question.

I understand that you don't like the simple vote, because it doesn't
allow you to express that your opinion on the init system depends on the
outcome of the coupling question (or vice versa).

This is all good in theory. In this particular situation, however, I
don't think this is a concern in practice. It seems pretty clear that
the default init system question is going to be decided by Bdale casting
vote. As I think you said yourself, it's not likely that anyones opinion
is going to change at this point.

In other words, the decision for the init system is a given, all that is
necessary is to finally bring it to a formal vote. In practice any
difference in your vote that would depend on the outcome of the coupling
question is not going to affect the result.

It seems that the only effect of adding all the coupling and GR stuff is
to make the ballot more complicated. If adding these options would
somehow result in a clear majority (without the need for a casting vote)
for one default init system, then to me this would look more like an
undesired voting artifact rather than a change in the majority opinion
of the CTTE.

Am I missing something?

Given the apparent challenges to draft an acceptable ballot, I think
Bdale's idea of keeping the vote truly simple should be reconsidered.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871tzeblb2@rath.org



Re: Additional CTTE Drafting Meeting useful?

2014-02-06 Thread Ansgar Burchardt
Hi,

On 02/06/2014 06:33, Russ Allbery wrote:
 Don Armstrong d...@debian.org writes:
 Would one more IRC meeting be useful to nail down the ballot options and
 their drafts?
 
 I personally suspect that we have exhausted the capacity of the TC to deal
 with this problem, and that spending more time on it may actually result
 in worse decisions than we would make right now.  Currently, I like each
 ballot we're getting less than I liked the previous one.  So I'm dubious.

Voting FD again due to failing to agree on a ballot might also indicate
that the secondary question (allowing dependencies on functionality only
available with a subset of existing init systems) have not been
reasonably discussed elsewhere (as required by 6.3.5).

In this case I suggest to decide just the question of the default init
system on Linux architectures first and address further details later if
no consensus can be found elsewhere. Finding the correct wording then
should be easier.

The init system vote could than have the options Bdale suggested
earlier, with addition of a suitable GR override paragraph. The latter
addition seemed at least uncontroversional except for a few wording issues.

 Chances are quite high that this will be decided by GR anyway at this
 point.

In that case we could also just start the GR now. I don't think we win
anything by delaying this decision further and further. In contrast, it
will mean we will fix *less* integration bugs before the freeze if the
init system changes.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f36793.6050...@debian.org



Bug#727708: Additional CTTE Drafting Meeting useful?

2014-02-06 Thread Ian Jackson
Ansgar Burchardt writes (Re: Additional CTTE Drafting Meeting useful?):
 In this case I suggest to decide just the question of the default init
 system on Linux architectures first and address further details later if
 no consensus can be found elsewhere. Finding the correct wording then
 should be easier.

I strongly object to this approach for the reasons I have given
already.

If I am given the opportunity to do so, if such a resolution is
proposed I will always propose amendments to settle the T vs L
question.

If I am not given the opportunity to do so, that would be because
someone proposes a set of options which do not answer the tying
question, and immediately calls for a vote.

Under the circumstances that would be IMO a clear breach of process.
I hope that now that I have made this perfectly clear, that this will
not happen.

Ian.


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



Re: Additional CTTE Drafting Meeting useful?

2014-02-05 Thread Ian Jackson
Don Armstrong writes (Additional CTTE Drafting Meeting useful?):
 Would one more IRC meeting be useful to nail down the ballot options and
 their drafts?

I'd be happy to do that.

 If you believe a meeting would be useful, please respond, and delete all
 of the non-working dates.
...

The remaining ones which I can make:

 February 10 2014 18:00:00 GMT
 February 11 2014 18:00:00 GMT
 February 13 2014 18:00:00 GMT
 February 14 2014 18:00:00 GMT
 February 17 2014 18:00:00 GMT

Ian.


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



Re: Additional CTTE Drafting Meeting useful?

2014-02-05 Thread Russ Allbery
Don Armstrong d...@debian.org writes:

 Would one more IRC meeting be useful to nail down the ballot options and
 their drafts?

I personally suspect that we have exhausted the capacity of the TC to deal
with this problem, and that spending more time on it may actually result
in worse decisions than we would make right now.  Currently, I like each
ballot we're getting less than I liked the previous one.  So I'm dubious.
Chances are quite high that this will be decided by GR anyway at this
point.

That said, I'm willing to give it a try if other folks disagree with me.

I can make the following dates:

 February 7 2014 18:00:00 GMT
 February 10 2014 18:00:00 GMT
 February 11 2014 18:00:00 GMT
 February 14 2014 18:00:00 GMT

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878utoajph@windlord.stanford.edu