Hi, Adding gdal-dev into the loop to get more feedback.
I actually discussed about that with Howard yesterday, and he suggested an even easier and least-effort solution. Do we actually need to migrate the existing Trac ticket database to github ? If not, we could just freeze Trac as read-only and decide that we just open the github repo for tickets... What would be nice to do is to rewrite a bit the git history of the current mirror so that commit messages like "Fix blabla (fixes #1234)" as rewritten as "Fix blabla (fixes https://trac.osgeo.org/gdal/ticket/1234)" A more complicated version of the above is that we would migrate only the open Trac tickets to github (so < 600 instead of 6000). And we would add in each open Trac ticket a message like "This ticket has been migated to https:// github.com/OSGeo/gdal/issue/4567", and close it. But that requires still some migration effort and deal with github API. A simpler variant of the above would be just close all those open tickets, assigning them to some milestone "closed-before-github-migration" with a message "Issue reporting has now been migrated to https://github.com/OSGeo/ gdal/issues. If that issue is still valid, please file a ticket over there". That can be done simply in a few seconds from Trac UI with a "batch modifiy" action. So to sum up my thoughts would be to: 1) Rewrite the github history (still need to figure out how to automate that) to fix references to Trac ticket, and force-push the result to github.com/ OSGeo/gdal. Note: that would invalidate current forks, so people with active work would probably have to rebase or to export as a patch and re-apply on top of updated Git repository. 2) Open github for filing tickets 3) Close all Trac tickets with assignment to a "closed-before-github- migration" milestone, and a message "Issue reporting has now been migrated to https://github.com/OSGeo/gdal/issues..." 4) Remove TICKET_CREATE rights to authenticated users of Trac Does that sound good ? Even On lundi 19 mars 2018 11:48:15 CET Mateusz Loskot wrote: > Hi Even, [...] > I've just pushed some basic stab at exporting Trac to GitHub > which I started prototyping in the beginning of October last year > https://github.com/mloskot/trac-to-github > > In October, Paul Ramsey released his bunch of scripts > https://github.com/pramsey/postgis-to-github/ > which, I think, cover the procedure more completely > and it's also based on GitHub API. > Shortly, instead of continue my development, Paul's solution may be > the way to go. > I haven't tried to run Paul's scripts, so I don't know what technically > is stopping the PostGIS migration, if anything. > > Generally, I think GitHub API approach is the way to go. > Annoyingly, the rate limits seem to lead to strange issues that I > experienced (eg. adding or adding 30 labels, some are left over). > This confirms what Thomas Bonfort was warning about and suggesting > to reach out to GitHub support stating you are running a batch import. > > I don't if Paul reached to GitHub support before performing PostGIS test > import https://github.com/pramsey/postgis-gh/issues > but it looks that a few thousands of tickets made it through. > > I've taken the liberty to CC to Paul perhaps he could shed more light. [...] > > Best regards, -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev