[python-committers] Transfer of power

[Brett Cannon]

On Mon, 16 Jul 2018 at 00:17 Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters <tim.peters at 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 :-)
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180716/938c437f/attachment-0001.html>