[gdal-dev] git(hub) migration ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] git(hub) migration ?

Even Rouault-2

Hi,

 

I've heard a few voices speaking/asking/begging for a git/github migration. At some point we'll certainly have to do it, as SVN vs git is beginning to feel more and more like CVS vs SVN 15 years ago.

 

I can see different options :

 

1) migrate to git, and remain within the OSGeo infrastructure. This is for example the case of GEOS which uses the Trac git plugin and the GOGS (or is gitea?) git hosting (https://git.osgeo.org/gogs/geos/geos.git). gogs/gitea tries to replicate most github functionalities, but feature parity is still not there (you cannot comment on a commit e.g). We could still offer github as a mirror, which would ease contributions a bit compared to the current git->svn situation, but the "Merge" button from github couldn't (shouldn't) be used.

 

2) migrate code to github, accept pull requests (PR) directly there. Tickets still managed in Trac. But then we have no automated link between Trac and github (unless there's a Trac plugin for that). A few other OSGeo projects are in a similar situation: QGIS with Redmine for tickets and github for PR&code, GeoServer with JIRA for tickets and github for PR&code. I've some experience with the QGIS situation: Redmine can include github commit references if the git commit message includes the ticket number. But, of course, the other way doesn't work: from github UI, the #XXXX link doesn't work (or would point to a unrelated PR with same number). So this is middly satisfactory, and a regression from our current situation.

 

3) migrate code and tickets to github. I guess this would match most (especially occasional) contributor wishes regarding the "social" aspect. What would be needed is Trac -> github ticket migration. Thomas Bonfort did it for MapServer at some point, but he lost the script if I remember well (I can see in https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues a number of possibilities listed). One issue also is we have numbers taken by existing github pull requests, so there would be collisions on import (we could decide either to sacrifice colliding Trac tickets, as there are really old, currently the colision appear for tickets older than 2003, or move them to an available github ticket number. Or to sacrifice existing PR, but there are a few pending ones)

There's also the valid concern about being tied with github.com regarding tickets. Recently I found https://github.com/josegonzalez/python-github-backup

which can backup code, issues, pull requests, etc.. using the github API.

Quickly tested it on their own repo. Seems to work (**), although a bit slow ( requires 2 GET per issue / pull request to retrieve extra details that are not retrieved by the global request you showed above). It has an incremental mode though which should make it efficient.

 

My synthetic view of the situation:

1) is a pure free sofware & free hosting approach. Relies on SAC being appropriately man and machine powered (same as with SVN / Trac currently)

2) mixed solution. we still have ownership on all our data (code & tickets). but the separation between a ticket system and code+PR isn't ideal from a usability point of view

3) offers probably the best contributor experience. We loose a bit of control, but a backup(*) strategy exists (at least for now). I'd tend to favor this approach.

 

I'm not sure if the current git mirror shouldn't be re-done from scratch. Its main drawback is that svn tags are reported as git branches, instead of git tags. I probably mis-configured things when I initiated the mirror a few years ago. Not completely sure this is worth the effort though. We can probably live with those existing mis-created tags, and use proper git tags for the future.

 

The release procedure / script would also have to be updated. Probably other things too.

 

There's also the question of the Trac Wiki, although this one might be defered for a later stage.

 

So this email is mostly to say I'm open to the idea, but I'd appreciate if someone else could take the lead on this. I'd be happy to help. A RFC to formalize the move would be needed.

 

Even

 

(*) Backup might not be the inappropriate term, since this implies that you can easily restore things. If github closes or requires (insane) fees for open source projects, those saved tickets will have to be re-injected in some to-be-defined alternative, but at least their content is readable (json)

 

(**) steps:

1) pip install github-backup

2) in github UI, create a personnal access token, so as to be able to use authenticated requests to github API, to bypass the rate limit of unauthenticated requests (you can use it even for repositories that you don't own)

3) github-backup -i -R python-github-backup josegonzalez --issues --issue-comments --issue-events --pulls --pull-comments --pull-commits -t ${your_github_token}

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Dmitry Baryshnikov-2

Hi Even,

I think this is great proposal. Github is modern tool for develop, code review and test software.

I like idea to migrate code and tickets (3). Not sure we need to migrate closed tickets. Also it worth thinking to migrate only the 2.x code tree. There are not so many releases in 2.x, so branches can be convert to tags manually.

Anyhow you made me thinking about this.
By the way this work may be the subject of GSoC 2018 (not sure if this allowed by program).
Best regards,
    Dmitry
06.09.17 16:14, Even Rouault пишет:
Hi,

I've heard a few voices speaking/asking/begging for a git/github migration. At some point 
we'll certainly have to do it, as SVN vs git is beginning to feel more and more like CVS vs SVN 
15 years ago.

I can see different options :

1) migrate to git, and remain within the OSGeo infrastructure. This is for example the case of 
GEOS which uses the Trac git plugin and the GOGS (or is gitea?) git hosting (<a class="moz-txt-link-freetext" href="https://">https://
git.osgeo.org/gogs/geos/geos.git). gogs/gitea tries to replicate most github functionalities, 
but feature parity is still not there (you cannot comment on a commit e.g). We could still 
offer github as a mirror, which would ease contributions a bit compared to the current git-
svn situation, but the "Merge" button from github couldn't (shouldn't) be used.
2) migrate code to github, accept pull requests (PR) directly there. Tickets still managed in 
Trac. But then we have no automated link between Trac and github (unless there's a Trac 
plugin for that). A few other OSGeo projects are in a similar situation: QGIS with Redmine for 
tickets and github for PR&code, GeoServer with JIRA for tickets and github for PR&code. I've 
some experience with the QGIS situation: Redmine can include github commit references if 
the git commit message includes the ticket number. But, of course, the other way doesn't 
work: from github UI, the #XXXX link doesn't work (or would point to a unrelated PR with 
same number). So this is middly satisfactory, and a regression from our current situation.

3) migrate code and tickets to github. I guess this would match most (especially occasional) 
contributor wishes regarding the "social" aspect. What would be needed is Trac -> github 
ticket migration. Thomas Bonfort did it for MapServer at some point, but he lost the script if I 
remember well (I can see in https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues a number of possibilities listed). One issue also is we have numbers 
taken by existing github pull requests, so there would be collisions on import (we could 
decide either to sacrifice colliding Trac tickets, as there are really old, currently the colision 
appear for tickets older than 2003, or move them to an available github ticket number. Or to 
sacrifice existing PR, but there are a few pending ones)
There's also the valid concern about being tied with github.com regarding tickets. Recently I 
found https://github.com/josegonzalez/python-github-backup 
which can backup code, issues, pull requests, etc.. using the github API. 
Quickly tested it on their own repo. Seems to work (**), although a bit slow ( requires 2 GET 
per issue / pull request to retrieve extra details that are not retrieved by the global request 
you showed above). It has an incremental mode though which should make it efficient.

My synthetic view of the situation:
1) is a pure free sofware & free hosting approach. Relies on SAC being appropriately man and 
machine powered (same as with SVN / Trac currently)
2) mixed solution. we still have ownership on all our data (code & tickets). but the separation 
between a ticket system and code+PR isn't ideal from a usability point of view
3) offers probably the best contributor experience. We loose a bit of control, but a backup(*) 
strategy exists (at least for now). I'd tend to favor this approach.

I'm not sure if the current git mirror shouldn't be re-done from scratch. Its main drawback is 
that svn tags are reported as git branches, instead of git tags. I probably mis-configured 
things when I initiated the mirror a few years ago. Not completely sure this is worth the 
effort though. We can probably live with those existing mis-created tags, and use proper git 
tags for the future.

The release procedure / script would also have to be updated. Probably other things too.

There's also the question of the Trac Wiki, although this one might be defered for a later 
stage.

So this email is mostly to say I'm open to the idea, but I'd appreciate if someone else could 
take the lead on this. I'd be happy to help. A RFC to formalize the move would be needed.

Even

(*) Backup might not be the inappropriate term, since this implies that you can easily restore 
things. If github closes or requires (insane) fees for open source projects, those saved tickets 
will have to be re-injected in some to-be-defined alternative, but at least their content is 
readable (json)

(**) steps:
1) pip install github-backup
2) in github UI, create a personnal access token, so as to be able to use authenticated 
requests to github API, to bypass the rate limit of unauthenticated requests (you can use it 
even for repositories that you don't own)
3) github-backup -i -R python-github-backup josegonzalez --issues --issue-comments --issue-
events --pulls --pull-comments --pull-commits -t ${your_github_token}




_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Mateusz Loskot
In reply to this post by Even Rouault-2
On 6 September 2017 at 15:14, Even Rouault <[hidden email]> wrote:

> Hi,
>
> I've heard a few voices speaking/asking/begging for a git/github migration.
> At some point we'll certainly have to do it, as SVN vs git is beginning to
> feel more and more like CVS vs SVN 15 years ago.
>
> I can see different options :
> [...]
>
> 3) migrate code and tickets to github. I guess this would match most
> (especially occasional) contributor wishes regarding the "social" aspect.
> What would be needed is Trac -> github ticket migration. Thomas Bonfort did
> it for MapServer at some point, but he lost the script if I remember well (I
> can see in
> https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues
> a number of possibilities listed). One issue also is we have numbers taken
> by existing github pull requests, so there would be collisions on import (we
> could decide either to sacrifice colliding Trac tickets, as there are really
> old, currently the colision appear for tickets older than 2003, or move them
> to an available github ticket number. Or to sacrifice existing PR, but there
> are a few pending ones)
>
> There's also the valid concern about being tied with github.com regarding
> tickets. Recently I found
> https://github.com/josegonzalez/python-github-backup
>
> which can backup code, issues, pull requests, etc.. using the github API.
>
>
> My synthetic view of the situation:
> [...]
> 3) offers probably the best contributor experience. We loose a bit of
> control, but a backup(*) strategy exists (at least for now). I'd tend to
> favor this approach.


As member of the development team, I'm very much support this motion
and move to GitHub.


> So this email is mostly to say I'm open to the idea, but I'd appreciate if
> someone else could take the lead on this. I'd be happy to help. A RFC to
> formalize the move would be needed.

If no one offers her/him-self to do it earlier, I am willing to offer myself to
migrate GDAL to GitHub in mid October.

Then, I will prepare RFC, ask for comments and voting,
develop Trac to GitHub workflow using existing tools and/or custom
scripting in Python,
test with sandbox mirror and push final migration.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Even Rouault-2
In reply to this post by Dmitry Baryshnikov-2

On mercredi 6 septembre 2017 21:16:46 CEST Dmitry Baryshnikov wrote:

> Hi Even,

>

> I think this is great proposal. Github is modern tool for develop, code

> review and test software.

>

> I like idea to migrate code and tickets (3). Not sure we need to migrate

> closed tickets.

 

I'd wish closed tickets to be migrated as well (I don't think this is more complicated to migrate both opened+closed tickets than just opened tickets). More than once I had to "svn blame" and was happy to be able to find a reference to a >10 year old ticket that gives some context for a change. Tickets are true assets of a project (at least for the developpers) (I was thinking to suggest the "fossil" SCM (*) which has the big advantage of including tickets in the repository, but of course we would miss the increased social collaboration aspect with such a choice :-))

 

> Also it worth thinking to migrate only the 2.x code

> tree.

 

I'd like the whole history to be preserved in the migration.

 

> There are not so many releases in 2.x, so branches can be convert

> to tags manually.

 

We could indeed probably create the tags manually without recreating the whole clone.

 

>

> Anyhow you made me thinking about this.

> By the way this work may be the subject of GSoC 2018 (not sure if this

> allowed by program).

 

I don't think that would be appropriate for GSoc which requires coding for a project. Infrastructure work like this is not allowed AFAIK.

 

Even

 

 

(*) https://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Tamas Szekeres
In reply to this post by Even Rouault-2
I would also prefer to go for #3 if possible, though I don't have enough experience how to make it happen.

Best regards,

Tamas


2017-09-06 15:14 GMT+02:00 Even Rouault <[hidden email]>:

Hi,

 

I've heard a few voices speaking/asking/begging for a git/github migration. At some point we'll certainly have to do it, as SVN vs git is beginning to feel more and more like CVS vs SVN 15 years ago.

 

I can see different options :

 

1) migrate to git, and remain within the OSGeo infrastructure. This is for example the case of GEOS which uses the Trac git plugin and the GOGS (or is gitea?) git hosting (https://git.osgeo.org/gogs/geos/geos.git). gogs/gitea tries to replicate most github functionalities, but feature parity is still not there (you cannot comment on a commit e.g). We could still offer github as a mirror, which would ease contributions a bit compared to the current git->svn situation, but the "Merge" button from github couldn't (shouldn't) be used.

 

2) migrate code to github, accept pull requests (PR) directly there. Tickets still managed in Trac. But then we have no automated link between Trac and github (unless there's a Trac plugin for that). A few other OSGeo projects are in a similar situation: QGIS with Redmine for tickets and github for PR&code, GeoServer with JIRA for tickets and github for PR&code. I've some experience with the QGIS situation: Redmine can include github commit references if the git commit message includes the ticket number. But, of course, the other way doesn't work: from github UI, the #XXXX link doesn't work (or would point to a unrelated PR with same number). So this is middly satisfactory, and a regression from our current situation.

 

3) migrate code and tickets to github. I guess this would match most (especially occasional) contributor wishes regarding the "social" aspect. What would be needed is Trac -> github ticket migration. Thomas Bonfort did it for MapServer at some point, but he lost the script if I remember well (I can see in https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues a number of possibilities listed). One issue also is we have numbers taken by existing github pull requests, so there would be collisions on import (we could decide either to sacrifice colliding Trac tickets, as there are really old, currently the colision appear for tickets older than 2003, or move them to an available github ticket number. Or to sacrifice existing PR, but there are a few pending ones)

There's also the valid concern about being tied with github.com regarding tickets. Recently I found https://github.com/josegonzalez/python-github-backup

which can backup code, issues, pull requests, etc.. using the github API.

Quickly tested it on their own repo. Seems to work (**), although a bit slow ( requires 2 GET per issue / pull request to retrieve extra details that are not retrieved by the global request you showed above). It has an incremental mode though which should make it efficient.

 

My synthetic view of the situation:

1) is a pure free sofware & free hosting approach. Relies on SAC being appropriately man and machine powered (same as with SVN / Trac currently)

2) mixed solution. we still have ownership on all our data (code & tickets). but the separation between a ticket system and code+PR isn't ideal from a usability point of view

3) offers probably the best contributor experience. We loose a bit of control, but a backup(*) strategy exists (at least for now). I'd tend to favor this approach.

 

I'm not sure if the current git mirror shouldn't be re-done from scratch. Its main drawback is that svn tags are reported as git branches, instead of git tags. I probably mis-configured things when I initiated the mirror a few years ago. Not completely sure this is worth the effort though. We can probably live with those existing mis-created tags, and use proper git tags for the future.

 

The release procedure / script would also have to be updated. Probably other things too.

 

There's also the question of the Trac Wiki, although this one might be defered for a later stage.

 

So this email is mostly to say I'm open to the idea, but I'd appreciate if someone else could take the lead on this. I'd be happy to help. A RFC to formalize the move would be needed.

 

Even

 

(*) Backup might not be the inappropriate term, since this implies that you can easily restore things. If github closes or requires (insane) fees for open source projects, those saved tickets will have to be re-injected in some to-be-defined alternative, but at least their content is readable (json)

 

(**) steps:

1) pip install github-backup

2) in github UI, create a personnal access token, so as to be able to use authenticated requests to github API, to bypass the rate limit of unauthenticated requests (you can use it even for repositories that you don't own)

3) github-backup -i -R python-github-backup josegonzalez --issues --issue-comments --issue-events --pulls --pull-comments --pull-commits -t ${your_github_token}

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

ginetto
In reply to this post by Mateusz Loskot
FYI in QGIS dev world we still not have found a clear and complete way
to migrate tracker from redmine to GH or GitLab.
More info and details can be asked to the key people that investigated
the problem... just asking in Dev list.

FYI we are still in a new updated redmine :/
Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**************************************************************************************************


On 6 September 2017 at 20:36, Mateusz Loskot <[hidden email]> wrote:

> On 6 September 2017 at 15:14, Even Rouault <[hidden email]> wrote:
>> Hi,
>>
>> I've heard a few voices speaking/asking/begging for a git/github migration.
>> At some point we'll certainly have to do it, as SVN vs git is beginning to
>> feel more and more like CVS vs SVN 15 years ago.
>>
>> I can see different options :
>> [...]
>>
>> 3) migrate code and tickets to github. I guess this would match most
>> (especially occasional) contributor wishes regarding the "social" aspect.
>> What would be needed is Trac -> github ticket migration. Thomas Bonfort did
>> it for MapServer at some point, but he lost the script if I remember well (I
>> can see in
>> https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues
>> a number of possibilities listed). One issue also is we have numbers taken
>> by existing github pull requests, so there would be collisions on import (we
>> could decide either to sacrifice colliding Trac tickets, as there are really
>> old, currently the colision appear for tickets older than 2003, or move them
>> to an available github ticket number. Or to sacrifice existing PR, but there
>> are a few pending ones)
>>
>> There's also the valid concern about being tied with github.com regarding
>> tickets. Recently I found
>> https://github.com/josegonzalez/python-github-backup
>>
>> which can backup code, issues, pull requests, etc.. using the github API.
>>
>>
>> My synthetic view of the situation:
>> [...]
>> 3) offers probably the best contributor experience. We loose a bit of
>> control, but a backup(*) strategy exists (at least for now). I'd tend to
>> favor this approach.
>
>
> As member of the development team, I'm very much support this motion
> and move to GitHub.
>
>
>> So this email is mostly to say I'm open to the idea, but I'd appreciate if
>> someone else could take the lead on this. I'd be happy to help. A RFC to
>> formalize the move would be needed.
>
> If no one offers her/him-self to do it earlier, I am willing to offer myself to
> migrate GDAL to GitHub in mid October.
>
> Then, I will prepare RFC, ask for comments and voting,
> develop Trac to GitHub workflow using existing tools and/or custom
> scripting in Python,
> test with sandbox mirror and push final migration.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Kurt Schwehr-2
I have a bunch of svn based scripts that I use daily, but I would be happily trash my current work flow for github.  

I would prefer option 3, but option 2 would be okay too.

I think that the utility of github pull requests is just too valuable to go with option 1.

I really need to rewatch the classic "Git for Ages 4 and up"... https://www.youtube.com/watch?v=1ffBJ4sVUb4

On Wed, Sep 6, 2017 at 1:26 PM, Luigi Pirelli <[hidden email]> wrote:
FYI in QGIS dev world we still not have found a clear and complete way
to migrate tracker from redmine to GH or GitLab.
More info and details can be asked to the key people that investigated
the problem... just asking in Dev list.

FYI we are still in a new updated redmine :/
Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**************************************************************************************************


On 6 September 2017 at 20:36, Mateusz Loskot <[hidden email]> wrote:
> On 6 September 2017 at 15:14, Even Rouault <[hidden email]> wrote:
>> Hi,
>>
>> I've heard a few voices speaking/asking/begging for a git/github migration.
>> At some point we'll certainly have to do it, as SVN vs git is beginning to
>> feel more and more like CVS vs SVN 15 years ago.
>>
>> I can see different options :
>> [...]
>>
>> 3) migrate code and tickets to github. I guess this would match most
>> (especially occasional) contributor wishes regarding the "social" aspect.
>> What would be needed is Trac -> github ticket migration. Thomas Bonfort did
>> it for MapServer at some point, but he lost the script if I remember well (I
>> can see in
>> https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues
>> a number of possibilities listed). One issue also is we have numbers taken
>> by existing github pull requests, so there would be collisions on import (we
>> could decide either to sacrifice colliding Trac tickets, as there are really
>> old, currently the colision appear for tickets older than 2003, or move them
>> to an available github ticket number. Or to sacrifice existing PR, but there
>> are a few pending ones)
>>
>> There's also the valid concern about being tied with github.com regarding
>> tickets. Recently I found
>> https://github.com/josegonzalez/python-github-backup
>>
>> which can backup code, issues, pull requests, etc.. using the github API.
>>
>>
>> My synthetic view of the situation:
>> [...]
>> 3) offers probably the best contributor experience. We loose a bit of
>> control, but a backup(*) strategy exists (at least for now). I'd tend to
>> favor this approach.
>
>
> As member of the development team, I'm very much support this motion
> and move to GitHub.
>
>
>> So this email is mostly to say I'm open to the idea, but I'd appreciate if
>> someone else could take the lead on this. I'd be happy to help. A RFC to
>> formalize the move would be needed.
>
> If no one offers her/him-self to do it earlier, I am willing to offer myself to
> migrate GDAL to GitHub in mid October.
>
> Then, I will prepare RFC, ask for comments and voting,
> develop Trac to GitHub workflow using existing tools and/or custom
> scripting in Python,
> test with sandbox mirror and push final migration.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Even Rouault-2

On samedi 9 septembre 2017 07:29:23 CEST Kurt Schwehr wrote:

> I have a bunch of svn based scripts that I use daily, but I would be

> happily trash my current work flow for github.

>

> I would prefer option 3, but option 2 would be okay too.

>

> I think that the utility of github pull requests is just too valuable to go

> with option 1.

>

> I really need to rewatch the classic "Git for Ages 4 and up"...

> https://www.youtube.com/watch?v=1ffBJ4sVUb4

>

 

We'll probably have to do a CONTRIBUTING.md whose one part would give hints for the common commands and workflows. Like recommandations for contributors to how to clean their pull requests to squash meaningless iterations (thinking to "try to fix Travis", "attempt 2", "hopefully this is good now", "arf, still not quite", ... style commits) into a clean history.

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Mateusz Loskot
On 9 September 2017 at 17:27, Even Rouault <[hidden email]> wrote:

> On samedi 9 septembre 2017 07:29:23 CEST Kurt Schwehr wrote:
>
>> I have a bunch of svn based scripts that I use daily, but I would be
>> happily trash my current work flow for github.
>> I would prefer option 3, but option 2 would be okay too.
>> I think that the utility of github pull requests is just too valuable to go
>> with option 1.
>> I really need to rewatch the classic "Git for Ages 4 and up"...
>> https://www.youtube.com/watch?v=1ffBJ4sVUb4
>
>
> We'll probably have to do a CONTRIBUTING.md whose one part would give hints
> for the common commands and workflows.

Yes, good idea.

If GDAL moves to GitHub according to the 3rd option, I think this could be
achieved via GitHub Issues and Pull Request templates,
along with the CONTRIBUTING and SUPPORT files.

https://help.github.com/articles/helping-people-contribute-to-your-project/

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: git(hub) migration ?

Daniel Morissette
In reply to this post by Even Rouault-2
Whatever option we go with, I agree that it is important to maintain the full history of code and tickets. In addition to the "svn blame" example that Even gave, being able to track the provenance of each line of code is also good practice for legal reasons.

Daniel


On 2017-09-06 2:40 PM, Even Rouault wrote:

On mercredi 6 septembre 2017 21:16:46 CEST Dmitry Baryshnikov wrote:

> Hi Even,

>

> I think this is great proposal. Github is modern tool for develop, code

> review and test software.

>

> I like idea to migrate code and tickets (3). Not sure we need to migrate

> closed tickets.

 

I'd wish closed tickets to be migrated as well (I don't think this is more complicated to migrate both opened+closed tickets than just opened tickets). More than once I had to "svn blame" and was happy to be able to find a reference to a >10 year old ticket that gives some context for a change. Tickets are true assets of a project (at least for the developpers) (I was thinking to suggest the "fossil" SCM (*) which has the big advantage of including tickets in the repository, but of course we would miss the increased social collaboration aspect with such a choice :-))

 

> Also it worth thinking to migrate only the 2.x code

> tree.

 

I'd like the whole history to be preserved in the migration.

 

> There are not so many releases in 2.x, so branches can be convert

> to tags manually.

 

We could indeed probably create the tags manually without recreating the whole clone.

 

>

> Anyhow you made me thinking about this.

> By the way this work may be the subject of GSoC 2018 (not sure if this

> allowed by program).

 

I don't think that would be appropriate for GSoc which requires coding for a project. Infrastructure work like this is not allowed AFAIK.

 

Even

 

 

(*) https://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201   

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev