[cfe-dev] Bugzilla migration is stopped again

[Anton Korobeynikov via cfe-dev]

Hello

> 1) Can't we calculate in advance the eventual ID of each issue. can't we determine that bugzilla PR12345 =  GH12345 + (some offset caused by previous issues in GH)?  - (assuming we always import in the same order, oldest first 1 at a time)
The thing is... it's not simple "+" here, the things are a bit more
complex, as we do have gaps in bugzilla id's as well. Some of the
issues were removed due to spam or GDPR requests. So we'd need to
track the things, but this is doable, yes provided that id mapping
that is done by GitHub is predictable. I... cannot be 100% sure as the
final transfer is done not by myself, but by GitHub support engineers
(in order not to trigger notifications on all 52k+ issues).

> Is that something that might be worth a try? or do you do this already and GH is messing it up?
The latter essentially. The references were properly built, but
towards the original archive repo. It is assumed that GH will rewrite
them during the transfer. This is the standard functionality and I was
assured that it works properly, it was tested, deployed, and worked
for many years, etc. etc. etc. Now we are caught halfway as we already
migrated ~13k issues to the main LLVM repo. As I said, I spotted the
problem by chance, checking for the circular links rewriting was not
in my checklist, when I checked links rewriting during the test
migration I checked essentially "one way" and everything was ok (one
needs to migrate both sides of the reference in order to see the
problem and apparently there were none of them in the test 100 issues
we migrated).

I'm meeting with GitHub folks today (morning Pacific Time) to discuss
the options. One option is to proceed with the transfer and rewrite
the stale links afterwards. But I'm wondering if there is a way to fix
the issue on GH side and what is the ETA.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University