On 5 June 2018 at 01:21, Huidae Cho <grass4u@gmail.com> wrote:
Yeah, that acquisition is bad news. Why can we just not use the OSGeo one?
This is my favourite choice
Just curious.
Huidae
--
ciao
Luca
www.lucadelu.org
Luca Delucchi <lucadeluge@gmail.com> schrieb am Mi., 6. Juni 2018, 00:26:
On 5 June 2018 at 01:21, Huidae Cho <grass4u@gmail.com> wrote:
Yeah, that acquisition is bad news. Why can we just not use the OSGeo one?
This is my favourite choice
Which of the two? Gitea or gitlab?
Will they be stable and maintained installations with backup strategy for the years to come?
Markus
Just curious.
Huidae
–
ciao
Luca
Hi,
2018-06-06 0:26 GMT+02:00 Luca Delucchi <lucadeluge@gmail.com>:
Yeah, that acquisition is bad news. Why can we just not use the OSGeo one?
This is my favourite choice
in this case we can always do GitHub/Gitlab mirrors for PRs. Ma
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On 6 June 2018 at 07:23, Markus Neteler <neteler@osgeo.org> wrote:
Which of the two? Gitea or gitlab?
gitea, gitlab is not working for me
Will they be stable and maintained installations with backup strategy for
the years to come?
I think like svn and trac. However the backup for the git repository
is not needed since all the history is present in each copy of the
project, maybe could be useful for issue and PR
Markus
--
ciao
Luca
www.lucadelu.org
On Tue, Jun 12, 2018 at 5:19 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 6 June 2018 at 07:23, Markus Neteler <neteler@osgeo.org> wrote:
Which of the two? Gitea or gitlab?
gitea, gitlab is not working for me
Luca, I think you need to be more specific.
…and this discussion should probably go to new thread.
Il mer 13 giu 2018, 04:13 Vaclav Petras <wenzeslaus@gmail.com> ha scritto:
gitea, gitlab is not working for me
Luca, I think you need to be more specific.
I was speaking about the gitlab instance on OSGeo server [0], it is not working for me… Otherwise I like gitlab it self and I’m already using it.
Is it more clear now?
Best
Luca
On Wed, Jun 13, 2018 at 12:21 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
Il mer 13 giu 2018, 04:13 Vaclav Petras <wenzeslaus@gmail.com> ha scritto:
> gitea, gitlab is not working for me
Luca, I think you need to be more specific.
I was speaking about the gitlab instance on OSGeo server [0], it is not
working for me... Otherwise I like gitlab it self and I'm already using it.
Ah 
Is it more clear now?
Yes! I was also surprised...
As I said: the OSGeo git services are IMHO under-staffed and would
require a dedicated budget. Could be a nice idea but the board needs
to support that.
Markus
Best
Luca
On 13 June 2018 at 22:07, Markus Neteler <neteler@osgeo.org> wrote:
As I said: the OSGeo git services are IMHO under-staffed and would
require a dedicated budget. Could be a nice idea but the board needs
to support that.
I don't think so, git on OSGeo server is working [0], and the board
also use it [1]. I don't see any problem, it is like trac or svn....
I also used it for an OSGeo code [2]
Markus
PS
Probably I will move most of my github repositories to OSGeo one and
gitlab according the code topic
[0] https://git.osgeo.org/gitea/
[1] https://git.osgeo.org/gitea/osgeo/todo/issues
[2] https://git.osgeo.org/gitea/lucadelu/gci_analyst
--
ciao
Luca
www.lucadelu.org
On Wed, Jun 13, 2018 at 7:16 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 13 June 2018 at 22:07, Markus Neteler <neteler@osgeo.org> wrote:
>
> As I said: the OSGeo git services are IMHO under-staffed and would
> require a dedicated budget. Could be a nice idea but the board needs
> to support that.
>I don't think so, git on OSGeo server is working [0], and the board
also use it [1]. I don't see any problem, it is like trac or svn....
I also used it for an OSGeo code [2]
I agree. Also remember that git is a distributed repository, so individual
developers would have their own "complete" repository. I assume less
maintenance compared to SVN.
Huidae
> Markus
>PS
Probably I will move most of my github repositories to OSGeo one and
gitlab according the code topic[0] https://git.osgeo.org/gitea/
[1] https://git.osgeo.org/gitea/osgeo/todo/issues
[2] https://git.osgeo.org/gitea/lucadelu/gci_analyst--
ciao
Lucawww.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team
Luca Delucchi <lucadeluge@gmail.com> schrieb am Do., 14. Juni 2018, 01:16:
On 13 June 2018 at 22:07, Markus Neteler <neteler@osgeo.org> wrote:
As I said: the OSGeo git services are IMHO under-staffed and would
require a dedicated budget. Could be a nice idea but the board needs
to support that.I don’t think so, git on OSGeo server is working [0],
… to some extent…
This is a new bug discovered in gitea, reported by Vicky from OSGeo:
https://github.com/go-gitea/gitea/issues/4246
Markus
and the board
also use it [1]. I don’t see any problem, it is like trac or svn…
I also used it for an OSGeo code [2]Markus
PS
Probably I will move most of my github repositories to OSGeo one and
gitlab according the code topic[0] https://git.osgeo.org/gitea/
[1] https://git.osgeo.org/gitea/osgeo/todo/issues
[2] https://git.osgeo.org/gitea/lucadelu/gci_analyst–
ciao
Luca
On Thu, Jun 14, 2018 at 6:44 PM, Markus Neteler <neteler@osgeo.org> wrote:
Luca Delucchi <lucadeluge@gmail.com> schrieb am Do., 14. Juni 2018, 01:16:
On 13 June 2018 at 22:07, Markus Neteler <neteler@osgeo.org> wrote:
>
> As I said: the OSGeo git services are IMHO under-staffed and would
> require a dedicated budget. Could be a nice idea but the board needs
> to support that.
>I don't think so, git on OSGeo server is working [0],
... to some extent...
This is a new bug discovered in gitea, reported by Vicky from OSGeo:
I still think that we should consider gitlab (there is self-hosted),
also due to existing gitea limitations:
https://github.com/go-gitea/gitea/issues/1029
IMHO we should not aim at replacing svn with simplest-possible-git but
also make use of the possibilities the related platforms offer
including commenting on commits, pull requests etc. Otherwise we can
just continue with svn.
BTW: A new non-profit style git platform just gets started:
https://about.teahub.io/
Cheers
Markus
On Mon, Jun 4, 2018 at 11:00 PM Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 4, 2018 at 10:50 PM, Martin Landa <landa.martin@gmail.com> wrote:
[...]
> Migration to *git* is planned in any
> caseWe simply need to decide between own hosting (incl. git repo by OSGeo)
and effectively commercial providers (github, gitlab, bitbucket, ...).
... a friendly ping...
What are the remaining open problems with
https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git
?
thanks,
Markus
As long as we do not depend on highly specific features of such a
platform, migration to another git based platform will remain "easy".We should carefully try to identify potential single points of failure
like service unstable, unmaintained in the long run, pay-only traps
and the like. But unless we use the standard features of git along
with maybe CI we are relatively flexible in choosing the platform.Just my 0.02 cents,
Markus
Hi,
so 15. 12. 2018 v 17:29 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
... a friendly ping...
What are the remaining open problems with
https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git
based on migrate.sh [0] I have created testing a git repo running
local gitlab instance at [1]. You can clone this repo using
$ git clone http://geo102.fsv.cvut.cz:8090/grass/grass.git
check branches
$ git branch -r
and tags.
$ git tag
Next important part refers to log messages and content filtering. In
repo mentioned above no filtering has been done since we haven't
decided which issue tracker will be used.
1) do we want to stick with trac.osgeo.org, then we need to set up a
testing trac instance with git integrated and do some real tests (then
ask osgeo sac?)
1a) than issue links like #xxx will work in trac instance but not in
git provider web interface (github, gitlab)
1b) or logs could be filtered to rewrite #xxx to URL, but in this case
we would need to set up git hook to modify new log messages in similar
way
2) do we want to use issue tracker of git provider and switch our trac
instance to read-only mode similarly as gdal devs did?
2a) in this case we need to do log messages filtering for sure
Ma
[0] https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git/migrate.sh
[1] http://geo102.fsv.cvut.cz:8090/grass/grass
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Hi,
so 29. 12. 2018 v 3:05 odesílatel Martin Landa <landa.martin@gmail.com> napsal:
and tags.
$ git tag
a little issue found: all tags has been marked with same date [1]. I
will fix it ASAP. Ma
[1] http://geo102.fsv.cvut.cz:8090/grass/grass/tags
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On 15/12/18 17:28, Markus Neteler wrote:
On Mon, Jun 4, 2018 at 11:00 PM Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Jun 4, 2018 at 10:50 PM, Martin Landa <landa.martin@gmail.com> wrote:
[...]Migration to *git* is planned in any
caseWe simply need to decide between own hosting (incl. git repo by OSGeo)
and effectively commercial providers (github, gitlab, bitbucket, ...).... a friendly ping...
What are the remaining open problems with
https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git?
thanks,
MarkusAs long as we do not depend on highly specific features of such a
platform, migration to another git based platform will remain "easy".We should carefully try to identify potential single points of failure
like service unstable, unmaintained in the long run, pay-only traps
and the like. But unless we use the standard features of git along
with maybe CI we are relatively flexible in choosing the platform.
FYI, there is a new kid on the block: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html.
Moritz