[Chris Jerdonek] > ... 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. > > [Brett Cannon] > 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. In the original message of that thread, the release manager had already made a decision, but was getting so much opposition to his position that he appealed to Guido. But the RM already had authority to make the decision. Highly contentious decisions will always be appealed to the full height of whatever bureaucracy exists ;-) It turned out Guido agreed with the RM in this case. The PEPs came later, and were much less contentious than the original under-time-pressure decision. Regardless, I agree with Chris that it would be good to spell out what to do if the Ultimate Authority can't, or won't, reach a decision on their own. Indeed, that's the exact position Guido just left us in ;-)
_______________________________________________ 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/
