Re: Status of proposal E (SC change + non-free-firmware in installer)
Gunnar Wolf <gwolf@debian.org> writes:
> Now, my thinking wandered off to the following timeline:
> almost-now o Voting is open with the A,B,C,D,E option set.
> | We know the Secretary has warned that some options
> | winning might trigger his obligation to mark the
> | vote as invalid.
> |
> weeks-from- o Vote concludes. Option A wins. The Secretary rules
> now | the vote invalid.
> |
> few-months- o GR for changing SC#5 is called, discussed, voted.
> future | There is no longer a SC conflict between
> | 2022/vote_003 and SC#5.
> |
> What would follow from here? Would the SC change automatically enable
> the Secretary to reinstate the winning option A for 2022/vote_003? Or
> are such rulings made (as would make sense!) for the "current
> reality"? Would running the same vote again be in place?
> Sorry for the hypothesizing, but I think it's important to udnerstand
> where we are and where would this lead us to.
If we happen to fall down this leg of the Trousers of Time, I would be
inclined to explicitly reinstate option A in any SC ballot options that
would make A consistent with the SC as revised.
In practice, I think this specific outcome is unlikely in that I expect
that if people were willing to change the SC to be consistent with option
A, they'd just vote my option E. The most likely case where option A
would win but not option E is if option E failed to get a 3:1 majority and
then option A was the favorite among the remaining options, but in that
case the SC amendment in the third step would presumably also fail to
gather a 3:1 majority.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: