<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 3:57 PM Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 3:55 AM Martin Landa <<a href="mailto:landa.martin@gmail.com" target="_blank">landa.martin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel<br>
<<a href="mailto:p.vanbreugel@gmail.com" target="_blank">p.vanbreugel@gmail.com</a>> napsal:<br>
> I have read about the procedure for contributors to the main grass repository. Question is, how are we going to deal with add-ons?<br>
><br>
> 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.<br>
<br>
in my opinion requesting PRs for `grass-addons` is maybe overkill. It<br></blockquote><div><br></div><div><br></div><div>If we don't care about the history and any mess in the grass-addons repository, then yes, we don't need pull requests.</div><div>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.</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">
must be somehow discussed anyway. If we suggest direct commits it's<br>
important to avoid not needed 'merge from master' commits [1]. The<br>
workflow must be clear (rebase always) to avoid such situations. It<br></blockquote><div><br></div><div>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.</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">
was not defined yet. Even suggested workflow related to the main<br>
repository is not clearly defined [2]. This must be improved in a near<br>
future.<br>
<br>
> 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?<br></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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.<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"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Anna</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Would be nice if g.extension (wingrass builds) supports distributed<br>
personal repos. I can imagine that it could be driven by a metadata<br>
file stored in central `grass-addons` repo. But someone need to<br>
implement it (g.extension, manual pages builds and wingrass builds).<br>
Would be cool.<br>
<br>
> With a central repository for all add-ons I guess it will be easier to maintain an overview like <a href="https://grass.osgeo.org/grass76/manuals/addons/" rel="noreferrer" target="_blank">https://grass.osgeo.org/grass76/manuals/addons/</a> and to create the windows binaries?<br>
<br>
Sure. But see my notes above.<br>
<br>
Ma<br>
<br>
[1] <a href="https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html</a><br>
[2] <a href="https://trac.osgeo.org/grass/wiki/HowToGit" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/wiki/HowToGit</a><br>
<br>
--<br>
Martin Landa<br>
<a href="http://geo.fsv.cvut.cz/gwiki/Landa" rel="noreferrer" target="_blank">http://geo.fsv.cvut.cz/gwiki/Landa</a><br>
<a href="http://gismentors.cz/mentors/landa" rel="noreferrer" target="_blank">http://gismentors.cz/mentors/landa</a><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></blockquote></div></div>
</blockquote></div></div>