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

Hello
> 1) Can't we calculate in advance the eventual ID of each issue.
can't we determine that bugzilla PR12345 =  GH12345 + (some offset caused by
previous issues in GH)?  - (assuming we always import in the same order, oldest
first 1 at a time)
The thing is... it's not simple "+" here, the things are a bit
more
complex, as we do have gaps in bugzilla id's as well. Some of the
issues were removed due to spam or GDPR requests. So we'd need to
track the things, but this is doable, yes provided that id mapping
that is done by GitHub is predictable. I... cannot be 100% sure as the
final transfer is done not by myself, but by GitHub support engineers
(in order not to trigger notifications on all 52k+ issues).
> Is that something that might be worth a try? or do you do this already and
GH is messing it up?
The latter essentially. The references were properly built, but
towards the original archive repo. It is assumed that GH will rewrite
them during the transfer. This is the standard functionality and I was
assured that it works properly, it was tested, deployed, and worked
for many years, etc. etc. etc. Now we are caught halfway as we already
migrated ~13k issues to the main LLVM repo. As I said, I spotted the
problem by chance, checking for the circular links rewriting was not
in my checklist, when I checked links rewriting during the test
migration I checked essentially "one way" and everything was ok (one
needs to migrate both sides of the reference in order to see the
problem and apparently there were none of them in the test 100 issues
we migrated).

I'm meeting with GitHub folks today (morning Pacific Time) to discuss
the options. One option is to proceed with the transfer and rewrite
the stale links afterwards. But I'm wondering if there is a way to fix
the issue on GH side and what is the ETA.

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

On 12/6/21 01:06, Anton Korobeynikov via Openmp-dev
wrote:
> Hello
> 
>> 1) Can't we calculate in advance the eventual ID of each issue.
can't we determine that bugzilla PR12345 =  GH12345 + (some offset caused by
previous issues in GH)?  - (assuming we always import in the same order, oldest
first 1 at a time)
> The thing is... it's not simple "+" here, the things are a
bit more
> complex, as we do have gaps in bugzilla id's as well. Some of the
> issues were removed due to spam or GDPR requests. So we'd need to
> track the things, but this is doable, yes provided that id mapping
> that is done by GitHub is predictable. I... cannot be 100% sure as the
> final transfer is done not by myself, but by GitHub support engineers
> (in order not to trigger notifications on all 52k+ issues).
> 
>> Is that something that might be worth a try? or do you do this already
and GH is messing it up?
> The latter essentially. The references were properly built, but
> towards the original archive repo. It is assumed that GH will rewrite
> them during the transfer. This is the standard functionality and I was
> assured that it works properly, it was tested, deployed, and worked
> for many years, etc. etc. etc. Now we are caught halfway as we already
> migrated ~13k issues to the main LLVM repo. As I said, I spotted the
> problem by chance, checking for the circular links rewriting was not
> in my checklist, when I checked links rewriting during the test
> migration I checked essentially "one way" and everything was ok
(one
> needs to migrate both sides of the reference in order to see the
> problem and apparently there were none of them in the test 100 issues
> we migrated).
> 
> I'm meeting with GitHub folks today (morning Pacific Time) to discuss
> the options. One option is to proceed with the transfer and rewrite
> the stale links afterwards. But I'm wondering if there is a way to fix
> the issue on GH side and what is the ETA.
> 
I would be in favor of proceeding and trying to rewrite the links later.
As for the metabugs, I was planning to use Milestones instead of metabugs
once the migration was complete, and I would be fine with converting all
the old metabugs to Milestones, so I don't consider broken metabugs to
be a blocker.

-Tom

I read your Dec 7th Updates from the google doc..

Could I summarize based on my understanding:

1) we already migrated in 1300 issues
2) there were a handful of issues in there previously (erroneously entered
because they didn't realize we had bugzilla before we hid them)
3) its not possible to remove the existing issues and start again
4) so if any of the links are wrong in the 1300 then we can't do anything
with them other than correct by hand? (is that correct?)
5) GitHub say they don't recommend post-migration writing? Do they mean
they don't recommend using an api to do that? Or doing it by hand?
6) We can edit the comments by hand (can you only edit your own comments or
can we edit someone else's comments, I'm thinking its only our own based
on
testing I've done with other repos)
        - isn't this a requirement in order to fix up the
"code-blocks"?
7) We can't really go back to bugzilla now we've imported the 1300
otherwise if those 1300 get edited they be out of date (I assume future
updates would be impossible)

Assuming there is no obvious/immediate fix, Do we have any choice but
to move ahead with the existing import and fix the comments by hand
retrospectively (assuming 6)

If we could identify the items needing editing (a list) I'd be happy to
volunteer to do some of them by hand. (Assuming we can edit the comments of
others)

MyDeveloperDay.

>
>
> I'm meeting with GitHub folks today (morning Pacific Time) to discuss
> the options. One option is to proceed with the transfer and rewrite
> the stale links afterwards. But I'm wondering if there is a way to fix
> the issue on GH side and what is the ETA.
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211207/b8bb5482/attachment.html>