[GRASS-dev] grass-addons on github

[Markus Metz]

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 at 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 at gmail.com>
wrote:
>
> Hi,
>
> pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
> <p.vanbreugel at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> 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/20190524/df2644d6/attachment.html>