[GRASS-dev] grass-addons on github

Tue May 28 08:14:04 PDT 2019

On Mon, May 27, 2019 at 3:12 AM Rainer M Krug <Rainer at krugs.de> wrote:

> Disadvantage: From the GitHub blog:
>
>
>    - Managing dynamic, rapidly evolving or heavily co-dependent
>    repositories with submodules can quickly become frustrating. This post was
>    focused on simple, relatively static parent-child repository relationships.
>    A future follow-up post will detail some strategies to help manage more
>    complex submodule workflows.
>
> Probably not the easiest and most stable solution…
>

In one project, we are using one submodule. Definitively not easy. I have
no idea how submodules would work with forks and PR. Additionally,
submodules do not help in making the broad changes across multiple modules.
AFAIU, Git subtrees would be similar.

Vaclav

> On 27 May 2019, at 08:55, Rainer M Krug <Rainer at krugs.de> wrote:
>
> 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) 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/
>
> 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.Krug at uzh.ch>
> Rainer at krugs.de
> Skype:     RMkrug
>
> PGP: 0x0F52F982
>
>
>
> _______________________________________________
> 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.Krug at uzh.ch>
> Rainer at krugs.de
> Skype:     RMkrug
>
> PGP: 0x0F52F982
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190528/a97e360b/attachment-0001.html>