On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.pet...@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. > 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 :-) > _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/