Hello all,
I would like to propose Davin Potts as core developer to take on the responsibility for maintaining the multiprocessing package.
I've been working with him on and off for over a year and found him to be highly skilled, thoughtful, and responsible. He is willing to devote time to a much neglected part of the standard library (186 open issues). He would be a valued member of the team.
I would be happy to serve as his mentor for his early contributions.
Raymond
Begin forwarded message:
Date: December 25, 2014 at 6:46:33 AM PST Subject: contributing to multiprocessing From: Davin Potts <davin@appliomics.com> To: Raymond Hettinger <raymond.hettinger@gmail.com>
Hi Raymond --
You asked if I'd be interested in becoming a maintainer for the multiprocessing package -- I've continued thinking about what I can do or trust myself to do and I think it'd be cool to make some serious ongoing contributions around multiprocessing.
A rambling set of thoughts from my looking into multiprocessing....
I've now read many (most?) of Jesse Noller's blog posts relating to multiprocessing, where it stands and where it should go, his calls for help. I've noted Richard Oudkerk's disappearance from the issue comments and mailing lists for a half year or so now -- people are still referencing him, asking for his take, in new issues from as recent as this past week. I'm still a bit unclear on how multiprocessing should ultimately relate to concurrent.futures though that discussion seems to be an ongoing one. Reading through those discussions makes me realize I must come from a different background (massive distributed computing, scientific computing, HPC) -- it's neat to read and try to understand what's going through other peoples' heads here.
I've spent a decent chunk of time now going through the outstanding issues against multiprocessing. As best as I can tell, I'd break the current set of 186 issues mentioning multiprocessing down like this:
- 50% are either junk or otherwise simply outdated-needing-proper-cleanup items,
- 30% are advocating changes to docs to cover edge cases they've encountered,
- 15% are Windows-specific problems needing investigation,
- the remaining 5% are more interesting or nasty topics.
Many of the edge cases people get surprised by in that 30% are complications related to Windows -- I think a goodly chunk of these problems could be prevented if the documentation were re-oriented a bit more (though documentation is not the answer to them all). The thought of documenting every little gotchya or niche these folks encounter is silly and won't help in practical terms. That said, there's enough of these problems to signal that something is definitely sub-optimal.
The overall volume of Windows-related issues reminds me very much of Trent Nelson telling me at the one point that he figured the real reason he was invited to become a committer was because he didn't at all mind working on Windows issues. In a twisted way, I kind of like sorting out Windows issues too.
I'd guess it'd take me 30-60 minutes to carefully go through each item in that big 50% chunk, bringing a healthy number to some closure in an iteration or two. That'll take a bit of time to chew through but seems important.
If I'm up for helping work through the backlog of issues, including debugging Windows issues, how should I start?
Davin