[SciPy-dev] How to handle code contribution with GSoC students ?
Tue May 5 02:12:35 CDT 2009
I hope you won't mind my bumping this thread.
So, what's the news ? Any consensus yet ? SVN on scipy.org w/ one
sandbox per student ? hg on external servers ? Yet another option ?
On May 1, 2009, at 9:16 AM, email@example.com wrote:
> On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
> <firstname.lastname@example.org> wrote:
>> Pierre GM wrote:
>>> On Apr 29, 2009, at 10:44 AM, Stéfan van der Walt wrote:
>>>> 2009/4/29 David Cournapeau <email@example.com>:
>>>>> I was wondering about the best way to handle code by students
>>>>> the upcoming GSoC. The year I participated, I already had write
>>>>> so the question did not come up. I think I would prefer starting
>>>>> 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
>> commit in the sandbox, and the mentor would be responsible for
>> 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
>> 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
>> 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
More information about the Scipy-dev