[GRASS-dev] Re: SoC 2007

GRASS GIS GRASS GIS developer
1

(cc grass-dev, hope you don't mind)

On 4/14/07, Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:

Hi!

Just writing to you to let you know that I have heard back from
Maximilian Maldacker (who will write the shortest path through free
vector space module).

He will introduce himself on the developer list soonish.

Hi,

I have seen that he posted to the grass-dev list - very good.

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.

Markus

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

2

Hello Markus/Wolf

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.

Paul

3

On 20.04.2007 13:07, Paul Kelly wrote:

Hello Markus/Wolf

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.

Google does provide space in code.google.com, so I guess we could use
that, I suppose, but the idea is that the community should also try the
students' code, during the summer, not only the mentor. But I can live
with having a grass_soc repository on code.google .com ,and then from
there I can commit say weekly working versions of the code to the main
GRASS CVS repository. Would that be OK with you people?

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

4

Hello Wolf

On Fri, 20 Apr 2007, Wolf Bergenheim wrote:

Google does provide space in code.google.com, so I guess we could use
that, I suppose, but the idea is that the community should also try the
students' code, during the summer, not only the mentor. But I can live
with having a grass_soc repository on code.google .com ,and then from
there I can commit say weekly working versions of the code to the main
GRASS CVS repository. Would that be OK with you people?

I don't see any reason why the students can't have CVS access so they can commit directly? When they think the code is ready for testing. But I expect it will be further into the summer before there is something ready to commit and thus a place to collaborate over the initial prototype is necessary.
Can other devlopers access the google repository too - I'm thinking of perhaps discussions on the mailing list when we want to point out something specific in the code.

Paul

5

On 20.04.2007 13:56, Paul Kelly wrote:

Hello Wolf

On Fri, 20 Apr 2007, Wolf Bergenheim wrote:

Google does provide space in code.google.com, so I guess we could use
that, I suppose, but the idea is that the community should also try the
students' code, during the summer, not only the mentor. But I can live
with having a grass_soc repository on code.google .com ,and then from
there I can commit say weekly working versions of the code to the main
GRASS CVS repository. Would that be OK with you people?

I don't see any reason why the students can't have CVS access so they
can commit directly? When they think the code is ready for testing.

Neither do I. Perhaps Markus has some points? And I'm sure that the
student's can determine when the code is working and when it is not.

But I expect it will be further into the summer before there is something
ready to commit and thus a place to collaborate over the initial
prototype is necessary.

That is true... and daily commits is something I think is mandatory for
the collaboration in SoC, just to be able to track the student progress.
So in that light I think that perhaps the code.google.com repository
might be the place. Another option I assume could be the addons svn, but
I'm not sure if people will like that either since it has also some
email commit log thing...

Can other devlopers access the google repository too - I'm thinking of
perhaps discussions on the mailing list when we want to point out
something specific in the code.

I think that read access can be given to the whole world. So yeah
anybody should be able to get any code from there. I also think that
they give a web-access just like in sourceforge.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

6

Wolf Bergenheim wrote on 04/20/2007 01:29 PM:

On 20.04.2007 13:56, Paul Kelly wrote:
  

Hello Wolf

On Fri, 20 Apr 2007, Wolf Bergenheim wrote:

Google does provide space in code.google.com, so I guess we could use
that, I suppose, but the idea is that the community should also try the
students' code, during the summer, not only the mentor. But I can live
with having a grass_soc repository on code.google .com ,and then from
there I can commit say weekly working versions of the code to the main
GRASS CVS repository. Would that be OK with you people?
      

I don't see any reason why the students can't have CVS access so they
can commit directly? When they think the code is ready for testing.
    
Neither do I. Perhaps Markus has some points? And I'm sure that the
student's can determine when the code is working and when it is not.
  
So far we have been pretty conservative granting CVS write access since
we have no
means to restrict the access (unless we move to SVN). We usually see
what/how a person
contributes, then grant access.
There is the GRASS Addons SVN which might be also of interest.

In general, we should find a viable solution which makes testing easy.
Helena suggested
to re-establish a contrib section as it was in GRASS 4.x.
Overall, after full SVN migration these things should be pretty easy to
handle.

But I expect it will be further into the summer before there is something
ready to commit and thus a place to collaborate over the initial
prototype is necessary.
    
That is true... and daily commits is something I think is mandatory for
the collaboration in SoC, just to be able to track the student progress.
So in that light I think that perhaps the code.google.com repository
might be the place. Another option I assume could be the addons svn, but
I'm not sure if people will like that either since it has also some
email commit log thing...
  

What is the problem with the email commit log? It's sent to this list:
http://grass.itc.it/mailman/listinfo/grass-commit-addons
Who wants can subscribe.

Can other devlopers access the google repository too - I'm thinking of
perhaps discussions on the mailing list when we want to point out
something specific in the code.

I think that read access can be given to the whole world. So yeah
anybody should be able to get any code from there. I also think that
they give a web-access just like in sourceforge.
  

We should take care to not spread the code too much around. Otherwise
connections will get
lost or at least tedious. Currently we have GRASS-CVS for the "real"
code and
GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons
SVN is
publicly readable, with password-controlled write access, web interface
and own
commit mailing list.

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

7

On Fri, Apr 20, 2007 at 04:10:14PM +0300, Wolf Bergenheim wrote:

On 20.04.2007 15:14, Markus Neteler wrote:
> Wolf Bergenheim wrote on 04/20/2007 01:29 PM:
>> On 20.04.2007 13:56, Paul Kelly wrote:
>
>>> But I expect it will be further into the summer before there is something
>>> ready to commit and thus a place to collaborate over the initial
>>> prototype is necessary.
>>>
>> That is true... and daily commits is something I think is mandatory for
>> the collaboration in SoC, just to be able to track the student progress.
>> So in that light I think that perhaps the code.google.com repository
>> might be the place. Another option I assume could be the addons svn, but
>> I'm not sure if people will like that either since it has also some
>> email commit log thing...
>>
> What is the problem with the email commit log? It's sent to this list:
> http://grass.itc.it/mailman/listinfo/grass-commit-addons
> Who wants can subscribe.

Paul had concerns of too many messages cluttering the list with SoC
commits. Personally I don't think it is a problem.

Nor me - a commit is a commit. Any they don't need to make
each single character modification a commit :slight_smile:

>>> Can other devlopers access the google repository too - I'm thinking of
>>> perhaps discussions on the mailing list when we want to point out
>>> something specific in the code.
>>>
>>>
>> I think that read access can be given to the whole world. So yeah
>> anybody should be able to get any code from there. I also think that
>> they give a web-access just like in sourceforge.
>>
> We should take care to not spread the code too much around. Otherwise
> connections will get
> lost or at least tedious. Currently we have GRASS-CVS for the "real"
> code and
> GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons
> SVN is
> publicly readable, with password-controlled write access, web interface
> and own
> commit mailing list.

Do people check out this code? Do people test it?

Besides documentation/flyer, it currently contains:

gipe/
gui/
i.landsat.dehaze/
r.boxcount/
r.boxcount.sh/
r.out.netcdf/
v.curvature/
v.strahler/

gui/ is under heavy development, also gipe/. The others are
single modules with varying level of testing.

My worry is that if we
only store code in the addons svn nobody will even bother to look at
it. (except for me).

Not sure about this. And also: you need first sort of functional
code to make tests as a user. This simply takes time.

But if I commit that code to the GRASS cvs people
will see it and even be tempted to test it, which is what we want. In
the end of SoC the code has to be submitted to Google anyway for review,
and that means at least one commit to the code.google.com repository if
I have understood things correctly. The whole point with the CVS access
was that we would make the SoC students feel welcome into the core GRASS
community, which would increase the chances of them sticking around
after the SoC. But I guess svn access will be good enough in that
puropse too.

Peronally, I thought of starting in SVN and then moving it to CVS
once there is relevant code. Meanwhile we have maybe done the
entire SVN migration and the problem disappears?

So, how do I go about requesting access to the addons svn? Can I also
request access on the behalf of Daniel Bundala and Maximilian Maldacker?

Sure.
They may just drop me an email.

Markus

8

Grass Addons seems like a good place for this. There is similar development
work going on there currently, ranging from possible new GIS modules to the
new GUI.

Michael

On 4/20/07 5:14 AM, "Markus Neteler" <neteler@itc.it> wrote:

Wolf Bergenheim wrote on 04/20/2007 01:29 PM:

On 20.04.2007 13:56, Paul Kelly wrote:
  

Hello Wolf

On Fri, 20 Apr 2007, Wolf Bergenheim wrote:

Google does provide space in code.google.com, so I guess we could use
that, I suppose, but the idea is that the community should also try the
students' code, during the summer, not only the mentor. But I can live
with having a grass_soc repository on code.google .com ,and then from
there I can commit say weekly working versions of the code to the main
GRASS CVS repository. Would that be OK with you people?
      

I don't see any reason why the students can't have CVS access so they
can commit directly? When they think the code is ready for testing.
    
Neither do I. Perhaps Markus has some points? And I'm sure that the
student's can determine when the code is working and when it is not.
  
So far we have been pretty conservative granting CVS write access since
we have no
means to restrict the access (unless we move to SVN). We usually see
what/how a person
contributes, then grant access.
There is the GRASS Addons SVN which might be also of interest.

In general, we should find a viable solution which makes testing easy.
Helena suggested
to re-establish a contrib section as it was in GRASS 4.x.
Overall, after full SVN migration these things should be pretty easy to
handle.

But I expect it will be further into the summer before there is something
ready to commit and thus a place to collaborate over the initial
prototype is necessary.
    
That is true... and daily commits is something I think is mandatory for
the collaboration in SoC, just to be able to track the student progress.
So in that light I think that perhaps the code.google.com repository
might be the place. Another option I assume could be the addons svn, but
I'm not sure if people will like that either since it has also some
email commit log thing...
  

What is the problem with the email commit log? It's sent to this list:
http://grass.itc.it/mailman/listinfo/grass-commit-addons
Who wants can subscribe.

Can other devlopers access the google repository too - I'm thinking of
perhaps discussions on the mailing list when we want to point out
something specific in the code.

I think that read access can be given to the whole world. So yeah
anybody should be able to get any code from there. I also think that
they give a web-access just like in sourceforge.
  

We should take care to not spread the code too much around. Otherwise
connections will get
lost or at least tedious. Currently we have GRASS-CVS for the "real"
code and
GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons
SVN is
publicly readable, with password-controlled write access, web interface
and own
commit mailing list.

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

9

Markus Neteler wrote:

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.

..

Peronally, I thought of starting in SVN and then moving it to CVS
once there is relevant code. Meanwhile we have maybe done the
entire SVN migration and the problem disappears?

I agree.

Hamish