[GRASS-dev] grass-addons on github

[Rainer M Krug]

I am no git expert, so this could be completely off. But as far as I understand it, git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>) are exactly for this purpose.

From their description:

It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.

Here’s an example. Suppose you’re developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available.

Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.


The different add-ons could be added as submodules, so they 
would be in separate repos, 
you don’t have to download all if you are only working on one, 
the core team can exclude them easily if they do not work anymore from the general build process (and re-add them as easy),
Are treated, when complaint (as mentioned the windows binaries) as one single repo.
Developers of add-ons do not need write access to the core repo

Here is another link to the GitHub blog on how they can be used: https://github.blog/2016-02-01-working-with-submodules/ <https://github.blog/2016-02-01-working-with-submodules/>

Cheers,

Rainer




> On 25 May 2019, at 17:04, Markus Neteler <neteler at osgeo.org> wrote:
> 
> On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
> <Stefan.Blumentrath at nina.no> wrote:
>> 
>> Hi,
>> 
>> Collecting addons in a central repo seems very valuable to me too, for all the reasons Vacslav mentioned.
> 
> +1
> 
>> I am no git expert either, but PRs should not be a big issue to do (unless you are VERY productive). People could merge their own PRs, no?
> 
> Exactly.
> 
>> Creating a PR, does not mean it has to be reviewed by another dev, right? In my organization colleagues even usr PRs for repos where they are the only contributor...
> 
> I also prefer PRs. At least the changes have a chance to be reviewed
> and appear more traceable.
> 
>> I would argue having procedures as equal as possible between addons and core is just beneficial. Less confusion, fewer guidelines to maimtain, possibility to have CI before things are merged, and training for new devs that evolve from addon-dev to core-dev...
> 
> +1^2
> 
> Cheers,
> Markus
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Orcid ID: 0000-0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office:	+41 (0)44 635 47 64
Cell:       	+41 (0)78 630 66 57
email:      Rainer.Krug at uzh.ch
		Rainer at krugs.de
Skype:     RMkrug

PGP: 0x0F52F982



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190527/82c7bc14/attachment.html>