On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.peters@gmail.com> wrote:
> [Chris Jerdonek]
>>
>> I don’t think we should assume that a stalemate would be okay in all
>> cases. There may be cases in which a decision has to be made (e.g. if
>> nothing changes, bad things will happen). I think one of the most important
>> roles a BDFL serves is to provide a mechanism of last resort to resolve such
>> stalemates should they ever arise. If the replacement we come up with can
>> itself stalemate, I think there will be a problem.
>
> Can you flesh that out with a plausible example? If "bad things can happen"
> relates to finances or legal issues, the problem is almost certainly the
> PSF's headache to resolve. If they don't relate to finances or legal
> issues, I'm unclear on what "bad" could mean. Guido's BDFL pronouncements
> were mostly about language and library design issues.
I only had in mind technical things. Non-technical things didn't cross
my mind. The types of cases I had in mind were (in the abstract) (1) a
feature is rolled out which later turns out to have a severe defect,
and so it needs to be fixed somehow, and people are divided on how it
should be fixed; (2) something changes outside of Python (e.g.
something OS related), which is or will cause a severe defect for
Python users, and people can't agree on how it should be fixed; and
(3) (a case you mentioned) there is a feature that everyone wants to
add, but people are split on some bike shed issue. It's true that a
stalemate for (3) wouldn't be so bad, but it would prevent something
that everybody wants.
For (1) and (2), I'm probably not the best person to provide an
example. But one case in the back of my mind that may have prompted my
reply and that might qualify was when there was a randomness-related
security issue in the summer of 2016. I believe this is the thread
that kicked it off (subject line: "BDFL ruling request: should we
block forever waiting for high-quality random bits?"):
https://mail.python.org/pipermail/python-dev/2016-June/144939.html
Things got so contentious on python-dev that, IIRC, at least one core
developer quit or was threatening to quit, and it prompted the
creation of a new mailing list (Security-SIG) due to the volume of
emails. See the number of emails the thread above spurred alone:
https://mail.python.org/pipermail/python-dev/2016-June/thread.html
To resolve the split, Guido ultimately chose PEP 524 over PEP 522.
But that's an extremely rare case. And even then, I would assume the council would have picked a BDFL delegate who would have made the utlimate decision. So even in a stalemate there's a way out by the council saying "not it" and pointing at someone else.
-Brett
> If you want to make a rule that the Elders cannot tie, the only way to do
> that is to say they'll all be impeached and replaced if they ever tie (as
> already noted by Łukasz, having an odd number of Elders doesn't prevent one
> from abstaining).
There's another alternative. You can make a rule that they're not
allowed to abstain (or some variant, like you have to choose someone
else if you need to recuse yourself). I'm a member of such a body in
fact (the San Francisco Elections Commission). If a member wants to
abstain, a member has to request it, and then the Commission has to
pass a majority vote to let the person to abstain. But we wouldn't
even have to have that extra provision.
--Chris
> And we'll keep replacing them until they stop tying. But
> we'll probably run out of volunteers after the first round of impeachments.
>
> Sneakier: add a rule that if the Elders tie, then the choice has to be made
> by the President of the PSF. Which, by sheer coincidence, is Guido :-)
>