[SciPy-dev] How to handle code contribution with GSoC students ?
Fri May 1 09:01:46 CDT 2009
> On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
> <email@example.com> wrote:
>> Pierre GM wrote:
>>> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>>>> 2009/4/29 David Cournapeau <firstname.lastname@example.org>:
>>>>> I was wondering about the best way to handle code by students for
>>>>> the upcoming GSoC. The year I participated, I already had write
>>>>> 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
>>>>> 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.
> Scipy-dev mailing list
With regards to the splines as I have not looked at this, shouldn't we
be using the various spline functions already in Scipy?
Actually I do think that getting the students (not just Gsoc ones) to
learn a DVCS is rather important and for the students it would 'foster'
experience that would be useful for them to work in other projects now
that many projects use or are moving to DVCS. Also, doesn't using a DVCS
remove the need for a sandbox?
More information about the Scipy-dev