[Python-Dev] Our failure at handling GSoC students

[Terry Reedy]

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&%40search_text=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