Re: Maintenance of multiprocessing module: there are a few stalled issues/patches

Did you help move the issues forward by reviewing and testing the patches, or otherwise commenting? If the multiple PRs on an issue are either/or, which seems better?
Thanks Terry for the reply. Are regular users supposed to keep reviewing even though the issue already has positive reviews or former change requests have been fixed and are now already "awaiting core review"? Here, the first pull request stalled, but the second one takes over and awaits review: - https://bugs.python.org/issue28053 - https://github.com/python/cpython/pull/9959 - https://github.com/python/cpython/pull/15058 Here, the first pull request is the bugfix which changes only 2 lines, so very little code to review. The second one adds the regression tests which were missing to show the existing issue: - https://bugs.python.org/issue30256 - https://github.com/python/cpython/pull/4819 - https://github.com/python/cpython/pull/16341 Here, the third pull request is the most recent one, has been reviewed and is now awaiting core review: - https://bugs.python.org/issue31171 - https://github.com/python/cpython/pull/3054 - https://github.com/python/cpython/pull/10563 - https://github.com/python/cpython/pull/13353 Here, the original author also has responded to change requests and asked for a review: - https://bugs.python.org/issue35727 - https://github.com/python/cpython/pull/11538 I've just been looking through the multiprocessing module and open issues and wondered why there were some small bugs/patches not being fixed/merged. Is this the "normal" patch cycle? Does it take years for bugs to get fixed in Python, even though patches are submitted? Just asking, I realize this sounds very negative, but I don't mean to be criticizing. Doing volunteer work myself, I understand that time is valuable and not always available. But I would have thought that there was no shortage of volunteers for Python.

On Wed, Feb 12, 2020, at 08:22, mailer@app.tempr.email wrote:
I've just been looking through the multiprocessing module and open issues and wondered why there were some small bugs/patches not being fixed/merged. Is this the "normal" patch cycle? Does it take years for bugs to get fixed in Python, even though patches are submitted? Just asking, I realize this sounds very negative, but I don't mean to be criticizing. Doing volunteer work myself, I understand that time is valuable and not always available. But I would have thought that there was no shortage of volunteers for Python.
Sadly, that is not that case.

On 13Feb2020 0156, Benjamin Peterson wrote:
On Wed, Feb 12, 2020, at 08:22, mailer@app.tempr.email wrote:
I've just been looking through the multiprocessing module and open issues and wondered why there were some small bugs/patches not being fixed/merged. Is this the "normal" patch cycle? Does it take years for bugs to get fixed in Python, even though patches are submitted? Just asking, I realize this sounds very negative, but I don't mean to be criticizing. Doing volunteer work myself, I understand that time is valuable and not always available. But I would have thought that there was no shortage of volunteers for Python.
Sadly, that is not that case.
The challenge is that the final review/merge steps require *trusted* volunteers, not just anyone with a bit of time. Anything that actually becomes part of Python is going to impact millions of people, so we have a responsibility to take that seriously and account for many more aspects than simply "does this fix my problem". As a result, volunteers have to develop a reputation before they are given permissions to sign off on changes by themselves, which becomes a bottleneck in taking on new volunteers. But it's also tough to build up a reputation when there's nobody to review your work, so the bottleneck becomes a cycle. Unlike a business, we don't have legal protection/recourse for bad decisions. When things break, other volunteers just have to stand up and cop the blame on behalf of the whole team. So we all stake our reputations on every new core developer, which also slows down the process. (FWIW, this is the same feedback I posted on that survey about hiring developers. "Sufficiently financially motivated" can be a reason to trust someone, but maybe not, and many in our community see it as a very good reason to openly *distrust* someone...) Cheers, Steve

On Wed, 12 Feb 2020 17:22:53 +0100 "mailer@app.tempr.email" <mailer@app.tempr.email> wrote:
I've just been looking through the multiprocessing module and open issues and wondered why there were some small bugs/patches not being fixed/merged. Is this the "normal" patch cycle? Does it take years for bugs to get fixed in Python, even though patches are submitted? Just asking, I realize this sounds very negative, but I don't mean to be criticizing. Doing volunteer work myself, I understand that time is valuable and not always available. But I would have thought that there was no shortage of volunteers for Python.
I would certainly not call it "normal", but it definitely has been "usual", unfortunately. One issue is that multiprocessing is a complicated module which has delicate interaction with the system. So it's not the kind of module that all core developers can confidently merge patches to. The multiprocessing maintainers (me, Davin Potts) have been fairly inactive recently. I'm trying to do a review from time to time - also on concurrent.futures - but it's usually low on my priority list. Feel free to ping me on a PR (@pitrou) if you think that it's ready for a core developer review. Regards Antoine.
participants (4)
-
Antoine Pitrou
-
Benjamin Peterson
-
mailer@app.tempr.email
-
Steve Dower