<div dir="ltr">Thank you very much for all the work on this Anton!<div><br></div><div>The steps outlined seem like it should work.</div><div><br></div><div>If I remember correctly, one of the main concerns here is making sure that one can still easily find issues based on existing bugzilla IDs in existing comments, commit messages etc.</div><div>Do I understand correctly that after the migration, for an existing reference to "PR1234", you'll need to go to <a href="https://github.com/llvm/llvm-bugzilla-import/issues/1234">https://github.com/llvm/llvm-bugzilla-import/issues/1234</a> to find it (after our bugzilla server has been shut down)?</div><div>That seems workable if we document that well.</div><div><br></div><div>One other area where I thought there was quite a bit of debate was about how components will map to labels; mainly triggered because current bug triagers and watchers are looking for how they will be able to set up filters to see the bug updates they are interested in.</div><div>I wonder what the most recent thinking is on that?</div><div><br></div><div>Thanks,</div><div><br></div><div>Kristof</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 10 jul. 2020 om 10:11 schreef Anton Korobeynikov via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear all,<br>
<br>
Over the last few weeks with the help of GH folks I've been exploring<br>
the options of Bugzilla migration. I believe finally we came to the<br>
viable solution which is detailed below.<br>
<br>
It turned out that GitHub has an internal project rehydration tool<br>
that could be used to populate the empty repo contents from the simple<br>
serialized format. There is a big advantage of this approach as<br>
compared to using GH API as we are not bound to various thresholds and<br>
throttling limits (remember, that we need to import 35k+ bz issues).<br>
The downside is that such rehydration requires the empty repo and we<br>
cannot delete the current llvm-project: this way we will lose<br>
releases, fork connections, stars and watches. Unfortunately, there is<br>
no way to recreate releases while keeping the origins dates, so this<br>
is a no-go for us. Losing forks connections would strongly affect<br>
downstream users as well. This allowed to formulate the following<br>
scheme:<br>
<br>
1. Migrate Bugzilla to a new repo, say, llvm-bugzilla-import using the<br>
internal storage format.<br>
2. Install redirects <a href="http://llvm.org/PR1234" rel="noreferrer" target="_blank">llvm.org/PR1234</a> => gh/llvm/llvm-bugzilla-import/issues/1234<br>
3. Wipe existing issues and pull requests<br>
4. Migrate all issues from llvm-bugzilla-import to llvm-project using<br>
GH API. Github will take about llvm-bugzilla-import/issues/1234 =><br>
llvm-project/issues/5678 redirects<br>
<br>
The only downside of this approach is that we will be seeing 30k<br>
events like "llvm-bugzilla-import/issues/1234 migrated to<br>
llvm-project/issues/5678".<br>
<br>
Here is the tentative timeline / list of action points:<br>
<br>
1. Collect the mapping email (used by bugzilla) => GH account name<br>
(used by issues). We are going to collect using different sources:<br>
- Auto-populating the mapping from the list of known committers<br>
- Asking GH API (works only if a person made their email public and<br>
only when allowed by local law)<br>
- Emailing everyone who submitted to Bugzilla over last year or<br>
maybe two asking to fill in the form with the GH username<br>
- We would likely allow a month or so to let everyone respond.<br>
2. While 1. is in progress, we will work on various format issues for<br>
migration. For this we will use probable first 1k issues or so. It<br>
would be nice to include some meta-bugs here to ensure we could<br>
re-recreate issues. Things to consider:<br>
- Comment migration (GH uses markdown everywhere, so we'd need to<br>
carefully escape bugzilla contents)<br>
- Components => labels mapping and migration<br>
- Linking between the issues. Maybe automatically replace PR1234 in<br>
the text with #1234 to enable auto linking.<br>
- Authorship: reporter / commenter<br>
- Attaches<br>
3. After we are sure everyone is ready, we will do the test migration<br>
of the whole bugzilla.<br>
- Estimate the necessary time it would be required to make such a transition.<br>
- Fix remaining issues, if any<br>
4. Put bugzilla into read-only mode and perform the final migration to<br>
llvm-bugzilla-archive<br>
5. Wipe issues / PRs in llvm-project repo and perform migration from<br>
llvm-bugzilla-archive to llvm-project<br>
6. Migration done. Probably bugzilla will be kept in read-only mode<br>
for some time just for the sake of consistency and should any issues<br>
be found.<br>
<br>
Any comments & ideas?<br>
-- <br>
With best regards, Anton Korobeynikov<br>
Department of Statistical Modelling, Saint Petersburg State University<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>