[Python-Dev] Our failure at handling GSoC students (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Tue Aug 6 21:26:41 CEST 2013
- Previous message: [Python-Dev] Make extension module initialisation more like Python module initialisation
- Next message: [Python-Dev] Our failure at handling GSoC students
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
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.
Regards
Antoine.
- Previous message: [Python-Dev] Make extension module initialisation more like Python module initialisation
- Next message: [Python-Dev] Our failure at handling GSoC students
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]