llvm dev - Dec 2021 - Bugzilla migration is stopped again

Dear All,

I hate to say this, but the migration was stopped again. Now it seems
that GitHub does not rewrite issue references properly during the
transfer (sick!). Let me show what the problem is exactly:

Consider two issues: A and B, where A will reference B and B will
reference A. In our case this is used to model various relations like
"duplicates / is duplicated by", "blocks / is blocked by",
"depends on
/ required by". So, in bz archive A will reference B as #B and B
will reference #A.

Now, let's migrate A. The references will be rewritten. #B =>
bz-archive#B and #A => llvm-project#A. However, after migration of B
only one reference is rewritten llvm-project#A => #A, the bz-archive#B
link in the issue A will not be rewritten and therefore a dangling
reference will appear.

For us this means that we will lose all links to duplicate issues, and
(more important!) to linked issues in the meta bugs.

I informed GitHub about the bug and I am waiting for their answer.

-- 
With best regards, Anton Korobeynikov,

This may be a dumb question, but could this just be an issue of forward
references (i.e. issue A references B, but B has not been transferred yet
so doesn't exist)?
If so, could the transfer be split into a two step process:
1. Open all issues with summaries only
2. Populate description, comments, labels, etc.

Please note that I have no idea how any of this GitHub or Bugzilla stuff
works, so this suggestion may be completely absurd.

On Fri, Dec 3, 2021 at 7:19 PM Anton Korobeynikov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear All,
>
> I hate to say this, but the migration was stopped again. Now it seems
> that GitHub does not rewrite issue references properly during the
> transfer (sick!). Let me show what the problem is exactly:
>
> Consider two issues: A and B, where A will reference B and B will
> reference A. In our case this is used to model various relations like
> "duplicates / is duplicated by", "blocks / is blocked
by", "depends on
> / required by". So, in bz archive A will reference B as #B and B
> will reference #A.
>
> Now, let's migrate A. The references will be rewritten. #B =>
> bz-archive#B and #A => llvm-project#A. However, after migration of B
> only one reference is rewritten llvm-project#A => #A, the bz-archive#B
> link in the issue A will not be rewritten and therefore a dangling
> reference will appear.
>
> For us this means that we will lose all links to duplicate issues, and
> (more important!) to linked issues in the meta bugs.
>
> I informed GitHub about the bug and I am waiting for their answer.
>
> --
> With best regards, Anton Korobeynikov,
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211203/d5b8c2bd/attachment.html>

How many issues are we talking about with circular dependencies? Small
enough for us to fix by hand on a need to basis? At present the lack of bug
tracker for 10 days is starting to be more painful than  the 100%
correctness of the data. My experience of multiple migrations to JIRA
systems from various legacy bug trackers that this is an iterative
processes at some point you say “That’s good enough” and you conclude that
historical issues aren’t looked at enough to worry about it, as long as
users can get back to the legacy system they can cross reference if
necessary

Once you open this up, most issues we tackle will be  new issues created in
GitHub.

Time to move forward, ideally we should have done these kinds of migrations
during the planning phase, but we didn’t and that’s a lesson learnt, but
let’s finish up the migration as is. Move on in my view it looks good
enough to use and you’ve done a good job but let’s not drag this out for 1%
of bugs we might not look at much!

My 2p worth

MyDeveloperDay



On Sat, 4 Dec 2021 at 00:19, Anton Korobeynikov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear All,
>
> I hate to say this, but the migration was stopped again. Now it seems
> that GitHub does not rewrite issue references properly during the
> transfer (sick!). Let me show what the problem is exactly:
>
> Consider two issues: A and B, where A will reference B and B will
> reference A. In our case this is used to model various relations like
> "duplicates / is duplicated by", "blocks / is blocked
by", "depends on
> / required by". So, in bz archive A will reference B as #B and B
> will reference #A.
>
> Now, let's migrate A. The references will be rewritten. #B =>
> bz-archive#B and #A => llvm-project#A. However, after migration of B
> only one reference is rewritten llvm-project#A => #A, the bz-archive#B
> link in the issue A will not be rewritten and therefore a dangling
> reference will appear.
>
> For us this means that we will lose all links to duplicate issues, and
> (more important!) to linked issues in the meta bugs.
>
> I informed GitHub about the bug and I am waiting for their answer.
>
> --
> With best regards, Anton Korobeynikov,
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211204/8eca75f4/attachment.html>

On Sat, Dec 4, 2021 at 1:19 AM Anton Korobeynikov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Dear All,
>
> I hate to say this, but the migration was stopped again. Now it seems
> that GitHub does not rewrite issue references properly during the
> transfer (sick!). Let me show what the problem is exactly:
>
> Consider two issues: A and B, where A will reference B and B will
> reference A. In our case this is used to model various relations like
> "duplicates / is duplicated by", "blocks / is blocked
by", "depends on
> / required by". So, in bz archive A will reference B as #B and B
> will reference #A.
>
> Now, let's migrate A. The references will be rewritten. #B =>
> bz-archive#B and #A => llvm-project#A. However, after migration of B
> only one reference is rewritten llvm-project#A => #A, the bz-archive#B
> link in the issue A will not be rewritten and therefore a dangling
> reference will appear.

To clarify, will those bz-archive#B references just not look as nice, or do
they not work at all? It was my understanding that bz-archive#B will
redirect to llvm-project#B2, in which case this doesn't seem overly
problematic.

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211204/98944b80/attachment.html>

Hi,

Some thoughts that just crossed my mind: what if we instead rewrite every
link (not only backward reference) to http://llvm.org/PR<XXXX> ; since
these links will continue to work and redirect, that would make all
possible link working as expected wouldn't it?

-- 
Mehdi


On Fri, Dec 3, 2021 at 4:19 PM Anton Korobeynikov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear All,
>
> I hate to say this, but the migration was stopped again. Now it seems
> that GitHub does not rewrite issue references properly during the
> transfer (sick!). Let me show what the problem is exactly:
>
> Consider two issues: A and B, where A will reference B and B will
> reference A. In our case this is used to model various relations like
> "duplicates / is duplicated by", "blocks / is blocked
by", "depends on
> / required by". So, in bz archive A will reference B as #B and B
> will reference #A.
>
> Now, let's migrate A. The references will be rewritten. #B =>
> bz-archive#B and #A => llvm-project#A. However, after migration of B
> only one reference is rewritten llvm-project#A => #A, the bz-archive#B
> link in the issue A will not be rewritten and therefore a dangling
> reference will appear.
>
> For us this means that we will lose all links to duplicate issues, and
> (more important!) to linked issues in the meta bugs.
>
> I informed GitHub about the bug and I am waiting for their answer.
>
> --
> With best regards, Anton Korobeynikov,
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211207/5ec67997/attachment.html>

Hi folks,

Anton, thank you so much for driving the migration and all the effort you
have invested!

We discussed the current situation and the options in the Infrastructure
Working Group meeting yesterday [1]. Our proposal is to give GitHub another
48 hours (i.e. Thursday EOB) to resolve the issue regarding missing links
in circular dependencies.

If it can't be resolved by that time, we propose to move forward with the
migration anyway. The data is there, we're only missing the links. From our
perspective this is something we can live with.

Best,
Christian on behalf of the Infrastructure Working Group


[1] https://github.com/llvm/llvm-iwg/issues/56#issuecomment-988090092

On Sat, Dec 4, 2021 at 1:19 AM Anton Korobeynikov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Dear All,
>
> I hate to say this, but the migration was stopped again. Now it seems
> that GitHub does not rewrite issue references properly during the
> transfer (sick!). Let me show what the problem is exactly:
>
> Consider two issues: A and B, where A will reference B and B will
> reference A. In our case this is used to model various relations like
> "duplicates / is duplicated by", "blocks / is blocked
by", "depends on
> / required by". So, in bz archive A will reference B as #B and B
> will reference #A.
>
> Now, let's migrate A. The references will be rewritten. #B =>
> bz-archive#B and #A => llvm-project#A. However, after migration of B
> only one reference is rewritten llvm-project#A => #A, the bz-archive#B
> link in the issue A will not be rewritten and therefore a dangling
> reference will appear.
>
> For us this means that we will lose all links to duplicate issues, and
> (more important!) to linked issues in the meta bugs.
>
> I informed GitHub about the bug and I am waiting for their answer.
>
> --
> With best regards, Anton Korobeynikov,
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211208/3bd2446e/attachment.html>