On 8 August 2016 at 12:37, Nick Coghlan <ncoghlan@gmail.com> wrote:
However, from an operations perspective, it means the discussion will move downstream to see whether we (Fedora) agree this is the right behaviour for the *system* Python, or whether we should patch that to throw the error instead of implicitly blocking. Such divergence would be unfortunate (if we ultimately decide to go that way), but managing disagreements with upstreams about appropriate default behaviour is one of the reasons distros *have* the ability to carry patches in the first place.
At the very least, I'll be proposing we do this while the 3.6 beta releases are in Fedora Rawhide as a way of gathering objective data about the scope of the problem from ABRT (Fedora's automatic bug reporting tool, which can automatically collect and submit Python stack traces, but can't readily detect system hangs).
For folks curious as to what I mean here, this isn't a declaration that Fedora *is* going to diverge from upstream in terms of the way os.urandom() behaves in Python 3.6+. Rather, it's a statement that I think we need more data directly from Fedora's users before deciding whether or not it makes sense to abide by the cross-platform upstream behaviour, or carry a patch that changes the behaviour specifically for the system Python installation: https://lists.fedorahosted.org/archives/list/python- devel@lists.fedoraproject.org/thread/UAB7JJ5VPW2W2QEERZ4HIQZZB3QMB2H5/ While the interests of Linux distro users and CPython upstream users are generally pretty well aligned, the alignment isn't 100%, and distros carrying patches on behalf of their user base is what makes up the difference. The Fedora Rawhide experiment I'm proposing in that email to the Fedora Python list should give us the data we (Fedora) need to decide whether or not this is one of those cases where it makes sense for us to carry a patch - if we get zero hits from the exception in ABRT, then it means the default blocking behaviour should be relatively safe (since people won't be encountering it), so we can drop the patch before the F26 Beta release, and Guido will have a solid data point backing up his design instincts. If we *do* get hits on the exception, then exactly what we do will depend on the nature of those hits, and in particular whether or not the change is helping folks find misconfigured Fedora environments they hadn't previously noticed, or if they're spurious notifications in situations where just blocking for a few hundred milliseconds would have resolved the problem on its own (as tested by inserting a "python -c 'import os; os.getrandom(1)" before whatever application startup is triggering the new exception). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia