Re: thinking twice about the new issue tracker

[Federico Bruni]

Il giorno mer 2 set 2015 alle 18:52, Federico Bruni 
<address@hidden> ha scritto:
> Il giorno mer 2 set 2015 alle 12:51, Federico Bruni 
> <address@hidden> ha scritto:
> > I'm running the import on github. It takes more time, even if I've 
> > been
> > whitelisted by github team. I'm currently at:
> > Issue: 659/4567
> >
> > Let's see how it works.
>
> Now, after 6 hours, I'm at 3500/4567.
> A bit slow because Github API has a rate limit of 5000 reqs/hour.
>
> I'm leaving this computer. I'll send the link tomorrow.

It took about 10 hours. You can see the result here:
https://github.com/fedelibre/lilyissues/issues

It works quite well. Status and labels are migrated correctly. 
Attachments are saved on Github server and displayed inline if they are 
images (Type-Ugly issues usually have image attachments).

There's only one minor problem: issue IDs are different (as explained 
in the google IssueExporter page):

"""
GitHub pull requests and issues share the same ID namespace, so it is 
not possible to keep the same Google Code issue IDs when exporting 
issues to GitHub.

You can however rewrite exported comments to update issue references on 
GitHub after all issues have been migrated. After you have exported all 
issues and comments, rerun the exporter adding the 
{{--rewrite_comments}} flag.

This flag will build up a mapping between former Google Code issues and 
their new home on GitHub, and then regenerate comments after replacing 
text like " issue #42 " or "bug10" to be " issue #53 " or " bug50 ", 
etc.
"""

But the old ID is mentioned at the beginning of each issue and internal 
links can be rewritten (as explained above).

Github, unlike Bitbucket, does not put any restriction to the number of 
contributors. And public repositories are free of charge.
So IMO this could have been a possible interim solution.