SoC: Require students to develop in a public repository?

[Max Bowsher <ma...@ukf.net>]

I'd like to suggest that for this year's SoC, we ask all students to do 
their day-to-day development in a public repository, be it at 
googlecode, svn.collab.net, red-bean.com or elsewhere.

One of the significant problems in previous years has been getting code 
to mentors in time for them to do a thorough review in time to write up 
their mid-term and final reports for Google - if the code under 
development is continuously available, it makes it possible for the 
mentor to maintain a better understanding of the evolving code, rather 
than having to review a large chunk of changes on a short deadline.

Max.

Re: SoC: Require students to develop in a public repository?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

C. Michael Pilato wrote:
> Karl Fogel wrote:
>> Max Bowsher <ma...@ukf.net> writes:
>>> I'd like to suggest that for this year's SoC, we ask all students to
>>> do their day-to-day development in a public repository, be it at
>>> googlecode, svn.collab.net, red-bean.com or elsewhere.
>>
>> +1 on svn.collab.net branches.
>>
>>> One of the significant problems in previous years has been getting
>>> code to mentors in time for them to do a thorough review in time to
>>> write up their mid-term and final reports for Google - if the code
>>> under development is continuously available, it makes it possible for
>>> the mentor to maintain a better understanding of the evolving code,
>>> rather than having to review a large chunk of changes on a short
>>> deadline.
>>
>> Completely agree.  I hope no one objects to just using branches in the
>> main repository for this.
> 
> Object?  On the contrary, I think it would help legitimize the GSoC 
> coders' efforts a bit more.  Think:  morale booster shot.
> 
> +1 on svn.collab.net branches.

+1 from me, also.  Even though I was already a full committer last year, 
it was really useful to have a branch specifically for my SoC work.

-Hyrum

Re: SoC: Require students to develop in a public repository?

["C. Michael Pilato" <cm...@collab.net>]

Karl Fogel wrote:
> Max Bowsher <ma...@ukf.net> writes:
>> I'd like to suggest that for this year's SoC, we ask all students to
>> do their day-to-day development in a public repository, be it at
>> googlecode, svn.collab.net, red-bean.com or elsewhere.
> 
> +1 on svn.collab.net branches.
> 
>> One of the significant problems in previous years has been getting
>> code to mentors in time for them to do a thorough review in time to
>> write up their mid-term and final reports for Google - if the code
>> under development is continuously available, it makes it possible for
>> the mentor to maintain a better understanding of the evolving code,
>> rather than having to review a large chunk of changes on a short
>> deadline.
> 
> Completely agree.  I hope no one objects to just using branches in the
> main repository for this.

Object?  On the contrary, I think it would help legitimize the GSoC coders' 
efforts a bit more.  Think:  morale booster shot.

+1 on svn.collab.net branches.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: SoC: Require students to develop in a public repository?

[Karl Fogel <kf...@red-bean.com>]

Max Bowsher <ma...@ukf.net> writes:
> I'd like to suggest that for this year's SoC, we ask all students to
> do their day-to-day development in a public repository, be it at
> googlecode, svn.collab.net, red-bean.com or elsewhere.

+1 on svn.collab.net branches.

> One of the significant problems in previous years has been getting
> code to mentors in time for them to do a thorough review in time to
> write up their mid-term and final reports for Google - if the code
> under development is continuously available, it makes it possible for
> the mentor to maintain a better understanding of the evolving code,
> rather than having to review a large chunk of changes on a short
> deadline.

Completely agree.  I hope no one objects to just using branches in the
main repository for this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org