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 <da...@appliomics.com> > To: Raymond Hettinger <raymond.hettin...@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 >
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
