[llvm-dev] [Openmp-dev] [cfe-dev] Bugzilla migration is stopped again

[Tom Stellard via llvm-dev]

On 12/6/21 01:06, Anton Korobeynikov via Openmp-dev wrote:
> 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.
> 

I would be in favor of proceeding and trying to rewrite the links later.
As for the metabugs, I was planning to use Milestones instead of metabugs
once the migration was complete, and I would be fine with converting all
the old metabugs to Milestones, so I don't consider broken metabugs to
be a blocker.

-Tom