Bdale Garbee <bdale@gag.com> writes:
> The fundamental problem is that I remain as convinced now as I was when
> I posted my last CFV that conflating multiple questions in a single
> ballot is a bad idea. Our voting system works exceptionally well when
> we're trying to choose between multiple alternatives for a single
> question. But as others have observed, trying to mix questions into a
> matrix of alternatives in a single ballot really complicates the
> process. I believe it both tempts us all to take a more tactical
> approach to voting than appropriate, and increases the risk of stumbling
> over corner cases in the process which could lead to surprising results.
Thank you. I'm strongly in agreement with this.
The discussion over coupling is very important. I will be continuing that
today, simultaneous with this. I think that Steve, Colin, and I are
actually very close to wording that all three of us agree on, and which I
suspect both Bdale and Keith will also agree with. I have some wording to
propose today.
I don't think that changes the merits of what Bdale says above. Yes,
there is interplay between the various things that we want to decide, but
iteratively narrowing the state space makes the ballots much more
comprehensible and avoids wandering into corner cases of our voting
method. I really disliked how tactical the analysis got with the combined
ballot; to me, it feels against the spirit of how we're expected to try to
resolve problems within Debian.
The ability to hold multiple iterative votes on different angles of the
question is a huge advantage of the TC process over the GR process. The
latter has a variety of constraints that makes holding multiple rounds of
votes incredibly painful. Given that our decision is likely to be
reviewed by GR no matter what happens, I think we can take advantage of
our faster voting turnaround to try to at least sketch out a few
reasonable courses of action that have support from sections of the TC,
which can in turn provide useful input into what GR questions people may
want to propose.
> - - - start ballot - - -
> We exercise our power to decide in cases of overlapping jurisdiction
> (6.1.2) by asserting that the default init system for Linux
> architectures in jessie should be
> D systemd
> U upstart
> O openrc
> V sysvinit (no change)
> F requires further discussion
> Should the project pass a General Resolution before the release of
> "jessie" asserting a "position statement about issues of the day" on
> init systems, that position replaces the outcome of this vote and is
> adopted by the Technical Committee as its own decision.
> - - - end ballot - - -
I vote:
D U O V F
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Attachment:
pgpEfZvHqsFc6.pgp
Description: PGP signature