Anton Korobeynikov via llvm-dev
2021-Dec-04 08:55 UTC
[llvm-dev] [cfe-dev] Bugzilla migration is stopped again
> 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
MyDeveloper Day via llvm-dev
2021-Dec-06 08:33 UTC
[llvm-dev] [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>