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