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

[Roman Lebedev via llvm-dev]

On Sat, Dec 4, 2021 at 12:58 PM Anton Korobeynikov
<anton at korobeynikov.info> wrote:
>
> > Is it really impossible to just completely remove all the current
> > issues and PR's in a repository and reset the counter, so that none of
> > this remapping is necessary in the first place?
> I asked this question many times at different levels. As far as I was
> told – yes. The bulk import could only happen to the empty repo. If
> you know how it could be done in another way – please let us know.
>
> > Alternatively, is it really impossible to, instead of moving issues,
> > ask github to just move the releases into that new repository and then
> > swap those two repositories (forks, stars, clones, etc.)?
> This is what we asked as well!. The answer was "there is no way".
> Maybe there is a way, but it would require some significant
> engineering effort from their side (e.g. additional development), so
> our request was refused.
>
> > I think all these problems are only because of the remapping, which
> > will be problematic regardless, because the in-source mentions aren't
> > getting rewritten, so there *will* be confusion regardless of whether
> > github succeeds in moving issues.
> Right. Do you have an idea how we can move forward?
Once the issues are imported into a clean llvm-project-NEW repository,
push tags into it, manually* recreate github releases - why do their dates
matter? - by manually* re-uploading all the manually uploaded assets,
then lock down the old llvm-project, rename it to llvm-project-obsolete,
mirror it's branches into the new repo, and finally rename the new
llvm-project-NEW to llvm-project. And delete llvm-project-obsolete.
As far as git is concerned, by now llvm-project repo is exactly
identical as the old one.

The only casualties will be unimportant things:
github stars, github forks, github release dates;
but if github can't be bothered to help with those,
it will serve as a forever reminder to the users that github is unreliable,
and false dependence should not be created on replaceable unreliable things.

* Surely it can be automated.

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