<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 11:41 AM, Martin Landa <span dir="ltr"><<a href="mailto:landa.martin@gmail.com" target="_blank">landa.martin@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br></blockquote><div>Hi Martin,<br><br>this is a good question. I actually don't know how I will do it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


I would suggest to create default/suggested/preferred source location<br>
for our GSoC projects.<br>
<br>
grass-addons/gsoc/<br>
grass-addons/gsoc/2014/<br>
grass-addons/gsoc/2014/metadata<br>
grass-addons/gsoc/2014/...<br>
<br></blockquote><div>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).<br>

<br>sandbox/gsoc<br>sandbox/gsoc/2014/<br>sandbox/gsoc/2014/metadata<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Till now students used different repos (grass-addons, github or in the<br>
individual cases it was also trunk).<br>
<br></blockquote><div>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).<br>

<br></div><div>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).<br>

<br></div><div>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, ...).<br>

<br></div><div>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).<br>

<br>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.<br>

</div><div><br></div><div>Vaclav<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When GSoC project is finished we can copy results to appropriate place<br>
(trunk, different grass-addons location). </blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What do you think? Martin<br>
<span class=""><font color="#888888"><br>
--<br>
Martin Landa * <a href="http://geo.fsv.cvut.cz/gwiki/Landa" target="_blank">http://geo.fsv.cvut.cz/gwiki/Landa</a><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</font></span></blockquote></div><br></div></div>