llvm dev - Jul 2020 - RFC: Bugzilla migration plan

> On Fri, 10 Jul 2020 at 09:11, Anton Korobeynikov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 3. Wipe existing issues and pull requests
> Does this really wipes the "auto-increment" IDs used by PRs and
issues
> and starts from zero again?
I will need to clarify whether we will be able to reset the counter or not
> > 4. Migrate all issues from llvm-bugzilla-import to llvm-project using
> > GH API. Github will take about llvm-bugzilla-import/issues/1234 =>
> > llvm-project/issues/5678 redirects
> If we're setting a redirect, PR1234 wouldn't hit #5678. We either
> guarantee that the IDs will be identical or we'll need a smart
> redirect that will know the delta (or 1:1 relationship).
Why? If you migrate the issue inside GH, then GH does the necessary
redirects on its side.

So, we will be taking care about PR1234 =>
llvm-bugzilla-import/issues/1234 redirect and github will further
redirect from llvm-bugzilla-import/issues/1234 to
llvm-project/issues/5678.

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

On Fri, 10 Jul 2020 at 16:20, Anton Korobeynikov
<anton at korobeynikov.info> wrote:
> Why? If you migrate the issue inside GH, then GH does the necessary
> redirects on its side.
>
> So, we will be taking care about PR1234 =>
> llvm-bugzilla-import/issues/1234 redirect and github will further
> redirect from llvm-bugzilla-import/issues/1234 to
> llvm-project/issues/5678.
David's reply is what I was referring to. All other PRXXX references
all over the place that won't change.

Over time, the bugs alive today will end up with two references, 1234
and 5678 and it will be confusing which bug you're talking about.

However, like David, I don't think that's a blocker. I expect the two
ranges to be disjoint, so no clashes.

LGTM otherwise. While I weirdly like Bugzilla, I think we'll be much
better off using anything else.

cheers,
--renato

> Over time, the bugs alive today will end up with two references, 1234
> and 5678 and it will be confusing which bug you're talking about.
Yes, I agree, this might be a problem, however I'm not 100% sure we
could reset the counter. Still we will see if we could ensure the same
numbering during the migration (e.g just keeping first ~250 bz issues
in the archive and try to continue the numbering in the llvm-project
repo). But at least the redirect would provide the mapping as a last
resort.

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