llvm dev - Dec 2021 - [cfe-dev] Bugzilla migration is stopped again

Trying to think of a solution that might help while we wait for github.

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)
2) Could you build up this mapping a priori?
3) Could you then spin through the bugzilla issues prior to migration
(assuming they are in some form you can manipulate, JSON, XML, TXT?)
etc...programatically changing the links to what they ultimately will be
before doing the migration?
4) Then import that into the github (new bugzilla-archive)
5) then copy those issues from one repo to another?
6) Assuming all ducks are lined up correctly wouldn't these broken links
now seemingly point to the correct links?

Is that something that might be worth a try? or do you do this already and
GH is messing it up?

MyDeveloperDay.

On Sat, Dec 4, 2021 at 8:55 AM Anton Korobeynikov <anton at
korobeynikov.info>
wrote:
> > How many issues are we talking about with circular dependencies? Small
> enough for us to fix by hand on a need to basis? At present the lack of bug
> tracker for 10 days is starting to be more painful than  the 100%
> correctness of the data.
> This affects:
>   - All issues closed due to being duplicates
>   - All meta bugs (including release-tracking ones)
>
> Maybe something else, but IMO the meta-bugs case is quite severe.
> Essentially we will lose all links from the meta-bug to the
> "downstream" bugs, or vice versa, or mixture depending on the
relative
> order of migration of meta-bug and the dependees. I will be meeting
> with GitHub folks on Monday to see what are the solutions.
>
> > Time to move forward, ideally we should have done these kinds of
> migrations during the planning phase, but we didn’t and that’s a lesson
> learnt, but let’s finish up the migration as is. Move on in my view it
> looks good enough to use and you’ve done a good job but let’s not drag this
> out for 1% of bugs we might not look at much!
> Well. The thing is: we checked and found lots of issues and introduced
> many workarounds.  I must admit that checking cyclic references after
> the migration was not in my checklist and I spotted this issue by
> accident. Ordinary references are migrated properly (both to source
> code and other issues) and this was checked. There was an assumption
> that basic github functionality would simply work. This was a mistake.
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211206/b7924fe3/attachment.html>

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