Re: What next?

[Justin Mason <jm...@jmason.org>]

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 <an...@objectstyle.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
> >

Re: What next?

[Jim Jagielski <ji...@jaguNET.com>]

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 <an...@objectstyle.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
>>>>
>

Re: What next?

[Bill Dudney <bd...@apache.org>]

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 <an...@objectstyle.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
>>>