[Overload-sig] Experimenting on real-world groups with potential solutions

[Kevin Ollivier]

HI Stephen,



On 6/25/16, 10:13 AM, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

>Kevin Ollivier writes:
>
> > Actually, I have yet to be convinced that there was anything
> > regarding os.urandom that needed discussing at all. The whole
> > discussing revolved around a hypothetical use case that, as far as
> > I am aware, is both pretty unlikely to happen and has never
> > actually even been reported.
>
>You have plenty of company, but the people who disgree with you are
>precisely those who have devoted many hours to getting up to speed on
>security issues, and to responding to them when they are reported in
>Python.  Guido was unwilling to make the call without advice from
>prominent OS-level security experts including the maintainer of the
>Linux CSPRNG functionality, which I think is indicative that there
>really was something to discuss.

Yes, but all of that served no purpose if they were debating a fix to a problem that we haven't even proved exists, much less is being experienced in the wild. 

> > I think this is actually a good example of how going straight to
> > the issue tracker would have led to a much different
> > outcome.
>
>Ah, but it *did* start on the tracker!  But the actual history was
>rather different from your thought experiment.  There was heated
>discussion of the issue over a 48- or 72-hour period, there was an
>impasse in the discussion, the Release Manager who technically has the
>authority to make the call decided it was above his pay grade, and
>brought in the BDFL -- and it was that decision that *started* the
>thread on python-dev.

Thanks, I went to the tracker and was able to find the tickets #27250 and #27266. 

Looking at them, though, I still don't see anything that refutes my point above. I see nothing in the os.urandom blocking tickets referencing a real world problem report. They just reference the CPython problem, which was fixed without needing to touch os.urandom.

Here's my point. If, when those tickets were created, someone asked for an actual, valid use case of the problem before proceeding, then as far as I can tell this whole discussion would never have happened. It would have stopped with the CPython fix, and we would not have lost contributors over it.

I'm pressing this because this problem is a very big deal. The democratic and distributed nature of open source often creates a tendency to focus on details rather than big picture. This leads to very real problems where devs are spending considerable time fighting over fixes to minor issues while being oblivious to much bigger problems, like, say, that due to changes in the market, the software they're building now only runs on a minority of the computers out there. [1] It can become a boiling frog situation.

Any large-scale open source project like this one needs tools and strategies that help keep things on track, and focused on the major issues. A better issue tracker can really help with this - I noticed that bugs.python.org pops uses the 'last activity' to sort by default. It should default to ticket priority and target release instead. There may also need to be some discussion with people who regularly work in the issue tracker about better prioritization and filtering of issues. 

And frankly, asking for a valid use case (or ideally a committable unit test) seems a no-brainer - without one you really can't test whether or not the fix works in the real world as designed. That's kind of important for creating robust software... ;-) On occasion, this requirement may prove overly burdensome, but this happens rarely enough that waving this requirement should be done only after careful consideration.

Thanks,

Kevin

[1] http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/

[2] 

>Steve