[SciPy-dev] How to handle code contribution with GSoC students ?

josef.pktd@gmai... josef.pktd@gmai...
Fri May 1 08:16:10 CDT 2009


On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
<david@ar.media.kyoto-u.ac.jp> wrote:
> Pierre GM wrote:
>> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>>
>>
>>> 2009/4/29 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
>>>
>>>>    I was wondering about the best way to handle code by students for
>>>> the upcoming GSoC. The year I participated, I already had write
>>>> access,
>>>> so the question did not come up. I think I would prefer starting with
>>>> code reviews, before giving them svn write access later. Do people
>>>> have
>>>> better suggestions ?
>>>>
>>> It's a good time to learn about distributed revision control :)  So
>>> yes, let's have review branches.
>>>
>>
>> A whole branch for modifications to only one specific submodule ?
>>
>
> One possibility is to have one sandbox / student, the student would only
> commit in the sandbox, and the mentor would be responsible for merging
> it into the trunk. The advantage of this technique is that the mentor
> can do all the work if desired (updating the branch from the trunk,
> merging, etc...).
>
> Using something like git, bzr or hg is easier for the mentor, but this
> assumes the student knows how to use them. I am not sure I want to
> bother students with new tools if they don't know them - getting
> familiar with the scipy code, how to build, run and test it is already
> enough as a barrier of entry.
>

The new stats.models code can be developed relatively isolated from
scipy, and added back in when it or parts are ready, i.e. tested and
reviewed. So, it's pretty flexible what the revision control structure
can be.

Since the current models are in launchpad under bzr revision control,
working with bzr branches would be the easiest for this.
For my own use, I'm keeping now bzr branches of scipy, and it works
reasonably well. (I haven't tried the hg svn bridge yet, but because
google code will allow mercurial repositories, using hg will become a
more attractive alternative.)

I would also find it useful, if stats.models can be released as a
standalone package during summer, so that it can be tried out by users
that don't build scipy or nipy themselves, and hopefully get more
feedback. Currently only bspline is in c, and it looks pretty broken
(I'm only getting segfaults out of it). Other than that it is a pure
python package that can be installed very easily.

Josef


More information about the Scipy-dev mailing list