[Python-Dev] Our failure at handling GSoC students
eliben at gmail.com
Tue Aug 6 21:43:40 CEST 2013
On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou <solipsis at pitrou.net> 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:
> 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
I would like to point out something that stands out in this list of issues:
such a method of producing dozens of patches simultaneously is extremely
unwise, unless there's a crucial piece of history I'm missing. It is much
more prudent to start with one or two exemplary modules, and if those fully
pass code review, send out patches for others. The reason is obvious - code
review may turn up problems or requests for change. Going backwards to
modify 57 patches is not something anyone would want to do.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev