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

[Pierre GM]

All,
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 ?

Cheers
P.
</bump>


On May 1, 2009, at 9:16 AM, josef.pktd at gmail.com wrote:

> On Fri, May 1, 2009 at 4:06 AM, David Cournapeau
> <david at 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 at 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
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev