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

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

> 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.
Thanks for your opinion. However, this was previously discussed and it
was decided that release dates do matter as well as forks. The latter
is even more important for downstream users.

Surely, if the community will re-decide that these are unimportant
things we can push the existing code into a blank archive fairly
quickly.
-- 
With best regards, Anton Korobeynikov