[Python-Dev] Our failure at handling GSoC students (original) (raw)

Terry Reedy tjreedy at udel.edu
Wed Aug 7 00:34:04 CEST 2013

On 8/6/2013 3:26 PM, Antoine Pitrou wrote:

I would like to point out that we currently fail at handling GSoC projects and bringing them to completion.

One cruel example is the set of PEP 3121 / PEP 384 refactorings done by Robin Schreiber: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40searchtext=pep+3121&submit=search&status=-1%2C1%2C3 Robin has produced many patches that seem to reach the stated goal (refactor C extension modules to take advantage of the latest PEPs about module initialization and extension types definition). Unfortunately, tackling both goals at the same time produces big patches with a lot of churn; and it is also not obvious the PEP 384 refactoring is useful for the stdlib (while the PEP 3121 refactoring definitely is). What didn't produce an alarm during Robin's work is that GSoC work is done in private. Therefore, other core developers than the mentor don't get to give an advice early, as would happen with any normal proposal done publicly (on the mailing-list or on the bug tracker). It is also likely that the mentor gets overworked after the GSoC period is over, is unable to finalize the patch and push it, and other core devs have a hard time catching up on the work and don't know what the shortcomings are.

There are 2 GSOC students working on Idle tests (mentored by Todd Rovito). Each file tested is a separate issue and separate patch. I have fallen behind reviewing them because of unexpected issues first with Idle and then with buildbots, but have been able to make some comments and some commits. I plan to do more before they disappear, and to get to everything eventually.

-- Terry Jan Reedy

More information about the Python-Dev mailing list