[gdal-dev] git(hub) migration ?

[Luigi Pirelli]

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 <mateusz at loskot.net> wrote:
> On 6 September 2017 at 15:14, Even Rouault <even.rouault at spatialys.com> 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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev