[GRASS-dev] gsoc preferred source location

[Vaclav Petras]

On Fri, May 23, 2014 at 11:41 AM, Martin Landa <landa.martin at gmail.com>wrote:

> Hi all,
>
> Hi Martin,

this is a good question. I actually don't know how I will do it.


> I would suggest to create default/suggested/preferred source location
> for our GSoC projects.
>
> grass-addons/gsoc/
> grass-addons/gsoc/2014/
> grass-addons/gsoc/2014/metadata
> grass-addons/gsoc/2014/...
>
> I don't think that grass-addons are appropriate. I consider grass-addons
as extension/addon/plugin repository, so thinks which you can install into
GRASS make sense there. r3.flow definitely does. I'm not so sure about
testing framework or metadata. sandbox make seems like more appropriate in
this case (no structure required or expected).

sandbox/gsoc
sandbox/gsoc/2014/
sandbox/gsoc/2014/metadata



> Till now students used different repos (grass-addons, github or in the
> individual cases it was also trunk).
>
> I think that this reflects the needs of different projects and students.
If the project is module grass-addons are appropriate (e.g. r3.flow). If
the student is experienced and he or she is changing current code in trunk,
than trunk seems like a right choice (e.g. Anna and you doing NVIZ in
wxGUI).

However, I don't have a clear idea about the bigger thinks which are
supposed to go in trunk but it would not be appropriate to do it from the
beginning because they are too complex and they change a lot during GSoC
(e.g. PyGRASS, metadata, testing framework). This does not apply only to
GSoC, temporal framework is in this category too. Branch seems like an
appropriate solution to me in this case. I would say that if we would using
git we would create a branch but I'm not sure how this work from the view
of svn workflow (I remember that temporal framework was developed outside
trunk without a branch).

I'm against external repositories (such as github, gitorious or bitbucket)
unless we make that official by creating an organization there and managing
the projects under this organization. This seems like a good idea. Some
organizations/projects also mirrors they repositories in github (e.g.
Eclipse; I've heard that this even brough them more contributions). In case
of GSoC, it would work as a sandbox (with a separate project/repository for
each GSoC project) and for the things which should be integrated into trunk
might make the syncing with trunk easier (but this would require somebody
with good git and svn knowledge to set it up). Speaking about that I would
also remind all about an idea of g.extension.git (or g.extension.github,
...).

Anyway, if you want conservative solution (no external services, no other
versioning system then svn), I would suggest sandbox rather than
grass-addons for the things which has unclear structure or needs to be
integrated into trunk (GUI updates, testing framework). The things which
are modules should go into grass-addons (hopefully even g.gui.* modules in
the future).

In other words I don't consider unified repositories for GSoC as important
or even feasible. Even trunk might be OK sometimes. I think unification
should be on the level of GSoC web pages (link(s) to source code location
can be in the table at the beginning), list of commits (e.g. done by query
in Trac) might be appropriate for things located/spread in trunk.

Vaclav

When GSoC project is finished we can copy results to appropriate place
> (trunk, different grass-addons location).



> What do you think? Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140523/802eacaf/attachment-0001.html>