On Tue, 6 Aug 2013 12:43:40 -0700 Eli Bendersky <eli...@gmail.com> wrote: > 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.
I definitely agree, but this is part of our failure too. A beginner contributor isn't supposed to know the best way to contribute if nobody tells him/her beforehand. Regards Antoine. _______________________________________________ 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