[GRASS-dev] Re: SoC 2007
paul-grass at stjohnspoint.co.uk
Fri Apr 20 06:07:19 EDT 2007
On Wed, 18 Apr 2007, Markus Neteler wrote:
>> On a side note; Markus (Frank, you may answer too ;)), what do you think
>> would be better: to have the SoC students commit through our regular CVS
>> (or svn if we have switched by 28.5) or as a GRASS extension?
> Concerning the main repository:
> We definitely won't switch to SVN quickly since it seems to be a slooooow
> process (sigh).
> Probably a GRASS SVN Addon would be best for now. We can easily
> migrate it into the main trunk then. All changes necessary in the libs can
> go directly into CVS of course so that the Addon stuff is compilable all
> the time.
>> In other
>> words do you think this should be an extension module or a core module?
>> I think it will be easier for the students to commit to the core, and
>> that way I think they will feel more like part of the GRASS team. Thoughts?
> For a module, the best breeding site might be the Addons SVN (however,
> with your vector/v.label.sa/ we do differently).
> Time to work out some rules for this. So I cc'ed to the dev list for
> further discussion.
I guess in this case some place is needed for the students and mentors to
work on code together. A place where its totally fine to put little
experimental things and break things on purpose and make many changes per
day. From that point of view I think a special repository separate from
the main GRASS one is required.
I feel the main GRASS repository should only be used for code that has
a reasonable chance of working, that you are ready to share with other
GRASS developers for testing. I don't think every small incremental
devlopment you make in your own tests should be committed, in particular
because it adds a lot of noise to the CVS commit mailing list and makes it
harder to track real changes. I feel we as developers should, *in general*
do a little bit of testing on our own and then commit something that we
think is reasonably likely to work. Of course there are lots of exceptions
to this. However in the case of summer of code students they need
somewhere to share work with the mentor and other interested developers
without the pressure of having to use the main CVS. Of course important
changes could be committed to the main CVS at regular intervals, like
Markus said (with regard to necessary changes to libraries etc.) but day
to day development should occur somewhere else IMHO.
More information about the grass-dev