[GRASS-dev] grass-addons on github

GRASS GRASS developer
1

Dear devs,

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Best regards,

Paulo

2

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
<p.vanbreugel@gmail.com> napsal:

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for `grass-addons` is maybe overkill. It
must be somehow discussed anyway. If we suggest direct commits it's
important to avoid not needed 'merge from master' commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It
was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central `grass-addons` repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

3

Hi,

pá 24. 5. 2019 v 9:54 odesílatel Martin Landa <landa.martin@gmail.com> napsal:

in my opinion requesting PRs for `grass-addons` is maybe overkill. It
must be somehow discussed anyway. If we suggest direct commits it's
important to avoid not needed 'merge from master' commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It
was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

draft added [1]. Ma

[1] https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforgrass-addonsrepository

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

4

On Fri, May 24, 2019 at 2:48 AM Paulo van Breugel <p.vanbreugel@gmail.com> wrote:

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

I think the first question to ask is if there are other reasons than technical ones to have all* addons in one repo. Having it in one (Subversion) repo meant that core devs can do general changes in all addons at once if needed and that all people can contribute to any other addon even when the original author doesn’t make any changes anymore** to the code. If the addons are individual repos, this would work only if maintainers are given access to them, e.g. by transferring ownership to the organization (which is what e.g. LANDIS-II seems to be doing [1]).

  • Not all 3rd party modules are of course there, just those from authors who choose to do that.
    ** Because of code was abandoned or the author simply does not have any time.

[1] https://github.com/LANDIS-II-Foundation

5

On Fri, May 24, 2019 at 3:55 AM Martin Landa <landa.martin@gmail.com> wrote:

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
<p.vanbreugel@gmail.com> napsal:

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for grass-addons is maybe overkill. It

If we don’t care about the history and any mess in the grass-addons repository, then yes, we don’t need pull requests.
But a lot of people who might be contributing there might not be familiar with the peculiarities of git (since even most core grass devs including me aren’t), so eventually we will end up with a lot of mess, which somebody will need to clean up. PR is a standard way to work on GitHub, so let’s use it. The same approach as for the main grass repo could be used.

must be somehow discussed anyway. If we suggest direct commits it’s
important to avoid not needed ‘merge from master’ commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It

I don’t quite get how to use rebase yet, but that’s the issue, it seems that if you use it incorrectly, it can be dangerous.

was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

We did this with couple more complicated addons, we do internal development in our git and then push it to the main repo when we want. I like the idea of having all addons in one repository, then you can provide the Windows binaries for them, that is also an incentive for contributers to put it there (you get windows binary, hosting of manuals, simple installation). But I get people want the distributed approach too.

Anna

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central grass-addons repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

6

On Fri, May 24, 2019 at 3:57 PM Anna Petrášová <kratochanna@gmail.com> wrote:

On Fri, May 24, 2019 at 3:55 AM Martin Landa <landa.martin@gmail.com> wrote:

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
<p.vanbreugel@gmail.com> napsal:

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for grass-addons is maybe overkill. It

If we don’t care about the history and any mess in the grass-addons repository, then yes, we don’t need pull requests.
But a lot of people who might be contributing there might not be familiar with the peculiarities of git (since even most core grass devs including me aren’t), so eventually we will end up with a lot of mess, which somebody will need to clean up. PR is a standard way to work on GitHub, so let’s use it. The same approach as for the main grass repo could be used.

must be somehow discussed anyway. If we suggest direct commits it’s
important to avoid not needed ‘merge from master’ commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It

I don’t quite get how to use rebase yet, but that’s the issue, it seems that if you use it incorrectly, it can be dangerous.

was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

We did this with couple more complicated addons, we do internal development in our git and then push it to the main repo when we want. I like the idea of having all addons in one repository, then you can provide the Windows binaries for them, that is also an incentive for contributers to put it there (you get windows binary, hosting of manuals, simple installation). But I get people want the distributed approach too.

I am personally in favor of a central repository, and I think you provided some important arguments in favor. It will require (for me) some time to get to know the peculiarities of git, especially as it seems it is easy to do something wrong.

Anna

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central grass-addons repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

7

Hi,

Collecting addons in a central repo seems very valuable to me too, for all the reasons Vacslav mentioned.

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? 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 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…

Cheers

Stefan

From: Anna Petrášová

Sent: Friday 24 May 15:57

Subject: Re: [GRASS-dev] grass-addons on github

To: Martin Landa

Cc: Paulo van Breugel, GRASS developers email list

On Fri, May 24, 2019 at 3:55 AM Martin Landa <landa.martin@gmail.com> wrote:

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel

<p.vanbreugel@gmail.com> napsal:

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for grass-addons is maybe overkill. It

If we don’t care about the history and any mess in the grass-addons repository, then yes, we don’t need pull requests.

But a lot of people who might be contributing there might not be familiar with the peculiarities of git (since even most core grass devs including me aren’t), so eventually we will end up with a lot of mess, which somebody will need to clean up. PR is a standard way to work on GitHub, so let’s use it. The same approach as for the main grass repo could be used.

must be somehow discussed anyway. If we suggest direct commits it’s

important to avoid not needed ‘merge from master’ commits [1]. The

workflow must be clear (rebase always) to avoid such situations. It

I don’t quite get how to use rebase yet, but that’s the issue, it seems that if you use it incorrectly, it can be dangerous.

was not defined yet. Even suggested workflow related to the main

repository is not clearly defined [2]. This must be improved in a near

future.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

We did this with couple more complicated addons, we do internal development in our git and then push it to the main repo when we want. I like the idea of having all addons in one repository, then you can provide the Windows binaries for them, that is also an incentive for contributers to put it there (you get windows binary, hosting of manuals, simple installation). But I get people want the distributed approach too.

Anna

Would be nice if g.extension (wingrass builds) supports distributed

personal repos. I can imagine that it could be driven by a metadata

file stored in central grass-addons repo. But someone need to

implement it (g.extension, manual pages builds and wingrass builds).

Would be cool.

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html

[2] https://trac.osgeo.org/grass/wiki/HowToGit

–

Martin Landa

http://geo.fsv.cvut.cz/gwiki/Landa

http://gismentors.cz/mentors/landa

grass-dev mailing list

grass-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/grass-dev

8

The main advantage of having all grass-addons in one repo is that they are easy to manage (for core devs).

The main disadvantage of having all grass-addons in one repo is that a contributor concerned about his single addon needs to get the whole repo, wasting disk space.

There are probably two different scenarios regarding contributions to grass-addons:

  1. a new addon: needs IMHO a PR, also if the contributor has write access to the addons repo

  2. modifications to an existing addon (bug fix, updated manual, new functionality, etc): if the contributor has properly validated the changes, the modifications could be pushed directly to the repo, without a PR. But since even people (more or less) familiar with git have different opinions on how to use git the correct way (as many correct ways as people having an opinion on it), it is probably safer to go through a PR.

my0.2cents,

Markus M

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

Hi,

Collecting addons in a central repo seems very valuable to me too, for all the reasons Vacslav mentioned.

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? 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 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…

Cheers
Stefan

From: Anna Petrášová
Sent: Friday 24 May 15:57
Subject: Re: [GRASS-dev] grass-addons on github
To: Martin Landa
Cc: Paulo van Breugel, GRASS developers email list

On Fri, May 24, 2019 at 3:55 AM Martin Landa <landa.martin@gmail.com> wrote:

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
<p.vanbreugel@gmail.com> napsal:

I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow the same protocol as for OSGEO/grass. If so, who will be responsible for approving pull requests? An alternative more like the old situation is that authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for grass-addons is maybe overkill. It

If we don’t care about the history and any mess in the grass-addons repository, then yes, we don’t need pull requests.
But a lot of people who might be contributing there might not be familiar with the peculiarities of git (since even most core grass devs including me aren’t), so eventually we will end up with a lot of mess, which somebody will need to clean up. PR is a standard way to work on GitHub, so let’s use it. The same approach as for the main grass repo could be used.

must be somehow discussed anyway. If we suggest direct commits it’s
important to avoid not needed ‘merge from master’ commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It

I don’t quite get how to use rebase yet, but that’s the issue, it seems that if you use it incorrectly, it can be dangerous.

was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

Or should add-on authors maintain their own repositories, and will there be a way to provide links to the authors repositories in a central place?

We did this with couple more complicated addons, we do internal development in our git and then push it to the main repo when we want. I like the idea of having all addons in one repository, then you can provide the Windows binaries for them, that is also an incentive for contributers to put it there (you get windows binary, hosting of manuals, simple installation). But I get people want the distributed approach too.

Anna

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central grass-addons repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

With a central repository for all add-ons I guess it will be easier to maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

9

* Stefan Blumentrath <Stefan.Blumentrath@nina.no> [2019-05-24 14:25:18 +0000]:

Hi,

Collecting addons in a central repo seems very valuable to me too, for
all the reasons Vacslav mentioned.

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?

Just sharing my thoughts: people should be very productive!, i.e. one
should commit as much as possible. There is a "squash" option to pack
several commits in one. This is doable independently, while `merge`-ing
or while `rebase`-ing. For the latter, i.e.:

git rebase -i HEAD~[NUMBER OF COMMITS]

Don't let the idea of potentially creating a mess keep you back. `git`
is fun because you can always unmess back.

During the work with Panos, and his guidance, I enjoyed doing a lot of
mistakes. And going back.

Nikos

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

Cheers Stefan

10

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
<Stefan.Blumentrath@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

11

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@osgeo.org> wrote:

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
<Stefan.Blumentrath@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@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@uzh.ch
Rainer@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

12

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…

On 27 May 2019, at 08:55, Rainer M Krug <Rainer@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@osgeo.org> wrote:

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
<Stefan.Blumentrath@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@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@uzh.ch
Rainer@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

grass-dev mailing list
grass-dev@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@uzh.ch
Rainer@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

13

On Mon, May 27, 2019 at 3:12 AM Rainer M Krug <Rainer@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@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@osgeo.org> wrote:

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath
<Stefan.Blumentrath@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@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@uzh.ch
Rainer@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

grass-dev mailing list
grass-dev@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@uzh.ch
Rainer@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev