On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
> > 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. > 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. Eli
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com