One possibility would be to create a GSoC branch from
trunk and give them SVN access to just that branch...
On May 26, 2006, at 2:46 PM, Bill Dudney wrote:
> Hi All,
>
> I prefer the patches approach. I know its a pain in the neck for
> the student but IMO its more likely to result in stuff we can
> maintain going forward (assuming the student is not able to
> continue after the SoC is over) because it has to be reviewed
> before being applied.
>
> Even on new app development it makes sense assuming that we get a
> patch once a week or once a day or whatever, as long as its small.
>
> If we can make SVK work (I'm interested too) then I'm OK with that
> as well as long as the patches are small.
>
> BTW: Since I'm offering my opinion I should probably sign up to
> help mentor. I won't have time to be full time mentor but would be
> glad to help review patches.
>
> TTFN,
>
> Bill Dudney
> MyFaces - http://myfaces.apache.org
> Cayenne - http://incubator.apache.org/projects/cayenne.html
>
>
>
> On May 24, 2006, at 1:24 PM, Justin Mason wrote:
>
>>
>> I'd like to hear people's experiences with SVK; my impression of
>> it (based
>> on its CVS support) was that it seemed pretty flaky. If that is
>> indeed
>> the case I wouldn't want to inflict it on the students...
>>
>> (To be honest, I'm leaning towards an SVN branch for our student
>> projects
>> in SpamAssassin.)
>>
>> --j.
>>
>> Andrus Adamchik writes:
>>> Heh, that's actually a more general problem with team development,
>>> both open source and commercial. I've seen people who would not
>>> commit their local work to CVS for weeks or months to postpone
>>> dealing with integration issues :-)
>>>
>>> So yes, communicating constant integration paradigm is important.
>>> And
>>> providing the right tools is what makes it practical.
>>>
>>> Andrus
>>>
>>> On May 24, 2006, at 2:21 PM, Garrett Rooney wrote:
>>>
>>>> On 5/24/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
>>>>> It looks like recommending SVK per Kevin's SVK suggestion is a
>>>>> good
>>>>> idea - there won't be a need for the external repo, and it will
>>>>> remove the reviewing bottleneck from the patch process.
>>>>
>>>> Just be sure that you don't end up with the student doing all their
>>>> work locally and not showing it to anyone until it's done. That
>>>> totally defeats the point of open development, peer review, etc.
>>>>
>>>> -garrett
>>>>
>
This archive was generated by hypermail 2.0.0 : Fri May 26 2006 - 15:00:01 EDT