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

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

On Mon, Dec 6, 2021 at 12:31 PM David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.
I also suggested that, but the thing that apparently throws the wrench
at that is that (as per @aKor's previous mail), the bugzilla issues id's
aren't consecutive, there are gaps, so just importing into a clean repo
(even without having to worry about moving issues into a new repo)
still won't result in 1:1 match to bugzilla issue id's. It would have
been nice
to know this beforehand. This means that missing issue id's would need to
be padded with empty issues.
> David
Roman
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hello David,
> 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.
The problem is that repo is not only code + issues. There are also:
  - Releases
  - Forks
  - Stars / Watches
  - All kinds of tokens and integrations
  - Maybe something else which I forgot right now

So, we'd also need to re-create releases, but we will lose all
metadata (e.g. there is no way to recreate releases using the correct
release dates) and there is no way to restore forks, so this will
affect all downstream users – they will essentially need to re-create
all their forks and move their private changes there. Currently there
are ~4.5k forks. I do not have information which forks are active.

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