On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek <chris.jerdo...@gmail.com> wrote:
> 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. > 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 :-) > > >
_______________________________________________ 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/