Hei,
Just wondering, regarding migration to git, would it be helpful to use AddOns (and possibly sandbox) as a test case?
There are probably not that many addon related tickets and the code is independent from trunk…
So what about moving addons first so we gain some experience…
But maybe that just causes extra work…
Anyway, let me know if / how amateurs like me can contribute / help with the migration process…
Cheers
Stefan
Hei,
Hi,
Just wondering, regarding migration to git, would it be helpful to use AddOns (and possibly sandbox) as a test case?
yes this could be a good idea, but first probably we have to choose which git platform to use. There are many possible options right now
Anyway, let me know if / how amateurs like me can contribute / help with the migration process…
same here
On Thu, Jan 24, 2019 at 3:12 AM Luca Delucchi <lucadeluge@gmail.com> wrote:
On Tue, 22 Jan 2019 at 08:09, Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:
Just wondering, regarding migration to git, would it be helpful to use AddOns (and possibly sandbox) as a test case?
yes this could be a good idea,
There is couple of different workflows which could be used for Addons besides one big repo considering what you can do with Git and Git hosting platforms, e.g. submodules. It would be good to collect advantages and disadvantages (e.g. on Trac wiki).
I’m not sure if sandbox is that interesting now, because on most platforms, even the self-hosted, you will probably have the option of personal repos.
One thing to figure out with both of them is that with Subversion, we you can just do svn cp to get data from one to the other when you promoting or depreciating modules (sandbox->addons->core, core->addons) when you had a checkout (svn checkout) of the whole repo (with grass, grass-addons, …). One command, all history preserved. What would be a Git equivalent of this?
but first probably we have to choose which git platform to use. There are many possible options right now
There were discussions about this at osgeo-discuss and here probably as well. If somebody would be willing to summarize it, it may help us to get started. Point of view of occasional contributors would be quite helpful here.
Thanks,
Vashek
Hi Vashek,
Thanks for the valuable info. Agree, that we should start collecting thoughts and options on a wiki page as preparation of a decision. I can setup a draft tonight (central European time), where I try to extract info from ML-archive.
Such a wiki page could contain the following things:
Relevant aspects to consider independent from platform chosen:
A collection of examples and experiences (from other projects (GDAL, QGIS, …) and links to ongoing discussions (osgeo-discuss).
Links to latest development / solutions for GRASS code base.
Evaluation of alternative hosting platforms (pros and cons). Maybe also a “popular vote” by users for consideration by PSC?
Kind regards,
Stefan
On Thu, Jan 24, 2019 at 3:12 AM Luca Delucchi <lucadeluge@gmail.com> wrote:
On Tue, 22 Jan 2019 at 08:09, Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:
Just wondering, regarding migration to git, would it be helpful to use AddOns (and possibly sandbox) as a test case?
yes this could be a good idea,
There is couple of different workflows which could be used for Addons besides one big repo considering what you can do with Git and Git hosting platforms, e.g. submodules. It would be good to collect advantages and disadvantages (e.g. on Trac wiki).
I’m not sure if sandbox is that interesting now, because on most platforms, even the self-hosted, you will probably have the option of personal repos.
One thing to figure out with both of them is that with Subversion, we you can just do svn cp to get data from one to the other when you promoting or depreciating modules (sandbox->addons->core, core->addons) when you had a checkout (svn checkout) of the whole repo (with grass, grass-addons, …). One command, all history preserved. What would be a Git equivalent of this?
but first probably we have to choose which git platform to use. There are many possible options right now
There were discussions about this at osgeo-discuss and here probably as well. If somebody would be willing to summarize it, it may help us to get started. Point of view of occasional contributors would be quite helpful here.
Thanks,
Vashek
Hi,
pá 25. 1. 2019 v 9:09 odesílatel Stefan Blumentrath
<Stefan.Blumentrath@nina.no> napsal:
General structure with regards to code that need hosting (or not): trunk, addonds sandbox, website, …
Tickets and history
see related ticket [1]. I wanted to setup real testing environment
where we can test trac and git integration (I just need to do the last
step, to restore backup of GRASS trac to sandbox). It could help us to
decide whether to use
* git + trac for issues
* git + issue tracker together (github,. gitlab, ...) -> trac swiched
to read only mode (probably except of wiki)
Ma
[1] https://trac.osgeo.org/grass/ticket/3722
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Fri, Jan 25, 2019 at 9:15 AM Martin Landa <landa.martin@gmail.com> wrote:
Hi,
pá 25. 1. 2019 v 9:09 odesílatel Stefan Blumentrath
<Stefan.Blumentrath@nina.no> napsal:
> General structure with regards to code that need hosting (or not): trunk, addonds sandbox, website, …
> Tickets and history
Hi Stefan,
did you already start the Wiki page (where)?
see related ticket [1]. I wanted to setup real testing environment
where we can test trac and git integration (I just need to do the last
step, to restore backup of GRASS trac to sandbox). It could help us to
decide whether to use* git + trac for issues
* git + issue tracker together (github,. gitlab, ...) -> trac swiched
to read only mode (probably except of wiki)Ma
For the collection, here some "further reading":
Recent opinions:
* https://www.reddit.com/r/devops/comments/8nro34/gitlab_vs_github_whats_the_right_hosting_platform/
* https://www.linuxjournal.com/content/opinion-github-vs-gitlab
GitLab compared to other DevOps tools
* https://about.gitlab.com/devops-tools/
GDAL (completed)
https://trac.osgeo.org/gdal/wiki/rfc71_github_migration (adopted)
QGIS migration (ongoing):
* https://github.com/qgis/QGIS/wiki/QGISbugtracker (pro/con table)
* https://github.com/qgis/QGIS/wiki/QGIS-Platform-migration-plan
(outdated, stalled?)
Importantly: let's start migrating to git and not wait forever (just
my 0.042 cents).
Markus
Hi,
btw:
I infrequently (~ weekly?) sync a mirror of GRASS GIS 7.6.svn in
github (https://github.com/mundialis/grass-gis-stable) based on
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_6/
in order to keep the related docker image up to date:
https://hub.docker.com/r/mundialis/grass-gis-stable/
So:
svn -> git push -> github -> hub.docker.com
After git push the rest runs automatically.
Just FYI,
Markus
Hi,
Now I created a first draft here:
https://trac.osgeo.org/grass/wiki/GitMigration
Contributions wellcome. I did not manage to collect all relevant discussion yet…
I also drafted a short simple user/developer survey (google form) that would aim at getting a better idea what people thing in general (and what requirements / whishes are). Would such a survey be of interest? I can share an editable link (off-list?) with those interested in improving it…
Kind regards,
Stefan
Fra: grass-dev grass-dev-bounces@lists.osgeo.org på vegne av Markus Neteler neteler@osgeo.org
Sendt: lørdag 26. januar 2019 18.11.10
Til: GRASS developers list
Emne: Re: [GRASS-dev] Migration to git, use addons as test case?
Hi,
btw:
I infrequently (~ weekly?) sync a mirror of GRASS GIS 7.6.svn in
github (https://github.com/mundialis/grass-gis-stable) based on
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_6/
in order to keep the related docker image up to date:
https://hub.docker.com/r/mundialis/grass-gis-stable/
So:
svn → git push → github → hub.docker.com
After git push the rest runs automatically.
Just FYI,
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi again,
Having browsed some of the historical discussion and arguments made, moving to gitlab.com seems like a natural choice to me personally nowadays (with github beeing bought by Microsoft). If we (and equally important also OSGeo) see a significant advantage of hosting it in OSGeo infrastructure it seems to be doable to import/export projects that way.
If competetive copy-left solutions (like e.g. sr.ht or gitea) emerge and there pop up push factors to leave gitlab.com pluss hosting on OSGeo infrastructure is considered robust enough I would expect migration tools will be developed / provided (like import / export functions in gitlab).
So, I would be happy with a PSC decision on git hosting to speed up the process (as I in fact don have strong opinions here), but if you want to collect user and developer perspectives in advance, the drafted google-forms-survey could be launched as soon as on Monday (tomorrow), if of interest.
Cheers
Stefan
Fra: grass-dev grass-dev-bounces@lists.osgeo.org på vegne av Stefan Blumentrath Stefan.Blumentrath@nina.no
Sendt: søndag 27. januar 2019 00.22.23
Til: Markus Neteler; GRASS developers list
Emne: Re: [GRASS-dev] Migration to git, use addons as test case?
Hi,
Now I created a first draft here:
https://trac.osgeo.org/grass/wiki/GitMigration
Contributions wellcome. I did not manage to collect all relevant discussion yet…
I also drafted a short simple user/developer survey (google form) that would aim at getting a better idea what people thing in general (and what requirements / whishes are). Would such a survey be of interest? I can share an editable link (off-list?) with those interested in improving it…
Kind regards,
Stefan
Fra: grass-dev grass-dev-bounces@lists.osgeo.org på vegne av Markus Neteler neteler@osgeo.org
Sendt: lørdag 26. januar 2019 18.11.10
Til: GRASS developers list
Emne: Re: [GRASS-dev] Migration to git, use addons as test case?
Hi,
btw:
I infrequently (~ weekly?) sync a mirror of GRASS GIS 7.6.svn in
github (https://github.com/mundialis/grass-gis-stable) based on
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_6/
in order to keep the related docker image up to date:
https://hub.docker.com/r/mundialis/grass-gis-stable/
So:
svn → git push → github → hub.docker.com
After git push the rest runs automatically.
Just FYI,
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
A bit late, my "outsider" view, even if some points are known/repeatedly
discussed:
- I prefer gitlab
- Pragmatically, however, github is still "bigger"
- Allow me (to reiterate) please: it is important to "open-up" to as many
contributors, any kind of, as possible--thus, a decentralised
repository is the way to go. Perhaps I am not that attached to SVN to
know it well, but I shouldn't be worried or need to check
multiple times each time I decide to commit something (in my case, the
Add-ons repository). I can break local GRASS GIS repositories as
many times without worries core developers will accept if and when they
judge some request is ready for merging in.
- If the PSC decides for an in-house solution (i.e. OSGeo's
infrastructure or else), consider perhaps some additional workload,
to implement/integrate authorisation and login mechanisms, or similar,
stuff that all "big" players have seamlessly working.
On/Off-topic:
- Add-ons should be only accepted along with some basic unit test
- Please consider also using new ways of interacting: slack or similar?
Cheers, Nikos
* Stefan Blumentrath <Stefan.Blumentrath@nina.no> [2019-01-27 10:37:02
* +0000]:
Hi again,
Having browsed some of the historical discussion and arguments made,
moving to gitlab.com seems like a natural choice to me personally
nowadays (with github beeing bought by Microsoft). If we (and equally
important also OSGeo) see a significant advantage of hosting it in
OSGeo infrastructure it seems to be doable to import/export projects
that way.If competetive copy-left solutions (like e.g. sr.ht or gitea) emerge
and there pop up push factors to leave gitlab.com pluss hosting on
OSGeo infrastructure is considered robust enough I would expect
migration tools will be developed / provided (like import / export
functions in gitlab).So, I would be happy with a PSC decision on git hosting to speed up the
process (as I in fact don have strong opinions here), but if you want
to collect user and developer perspectives in advance, the drafted
google-forms-survey could be launched as soon as on Monday (tomorrow),
if of interest.Cheers
Stefan