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

> 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?

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

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

On 04/12/2021 09:58, Anton Korobeynikov via llvm-dev
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.
> 
If I understand the GitHub process correctly, PR / issue numbers are 
monotonic integers that cannot be rolled back or modified because they 
are used in cross-referencing and are externally visible.  The mapping 
from repository to name; however, is mutable (with big warnings when you 
press the button because it breaks the aforementioned cross-referencing 
and external links).

It should be possible to:

  1. Create a new empty private GitHub project.
  2. Import all bugs, with the same bug numbers.
  3. Make the project public.
  4. Pull the entire contents of the current repo to the new project.
  5. Delete the llvm-project project (or rename it to llvm-project.old 
or something).
  6. Rename the new project to llvm-project

Steps 5 and 6 can't be atomic, so this will break everything that tries 
to access the repo between steps 5 and 6, but that should be about 30 
seconds of downtime.  The end result should be a llvm/llvm-project 
GitHub project containing the current git repo and the issues from 
Bugzilla but not any of the existing issues / PRs on that repo.

David