After the discussion in the forums regarding the migration, we agreed that Robert would get in touch with GitHub to find out if they could help us post the new GitHub issues under the handles we've mapped to the original contributors on Bugzilla. He learned there's no way to do that directly.

They suggested it might be possible by using an export tool that GitLab Enterprise has (yes, GitLab, not GitHub) to get the issues from Bugzilla to GitLab, then using GitHub for Business to import those issues to GitHub from GitLab. On the surface, that doesn't really look feasible. At a minimum, it seems that would require every one who submitted a Bugzilla issue to also have a GitLab account.

However, he did learn that GitHub has a hidden API we can use that will be an improvement on what we have now. Importantly, it will allow us to bypass rate limits, making the whole process go a lot more quickly. That in turn will allow us to post each comment on a Bugzilla issue as a separate comment on the GitHub issue.

Our current plan is to go for the latter option. Specifically regarding the issues:

• everything will be posted to GitHub under a dummy account
• the Bugzilla handle of the author of each issue will be in the GitHub issue's title
• a link to the Bugzilla issue will be added in the initial comment
• the author of each issue and everyone on the CC list will have their GitHub handles @ tagged in the initial comment
• each comment on the Bugzilla issue will be posted separately on the GitHub issue (I need to verify with Robert that he'll tag the GitHub handle of any comment author who isn't already in the CC list)
• text from Bugzilla will be posted to GitHub in Markdown code blocks to avoid formatting issues
• GitHub labels will be created from Bugzilla keywords and applied to the new GitHub issues as appropriate
• the original Bugzilla issue will be updated with a link to the new GitHub issue and a note that further comments on the Bugzilla issue may not be seen

I think that addresses most of the concerns raised about the format of the issues in the previous discussion. Are we missing anything?

At some point after the migration, we'll put the Bugzilla instance into read-only mode. We've never intended to shut it down. We need to migrate it to a server under our control eventually. Once it's set to read-only, we'll want dlang-bot to still be able to have write access so that it can close issues on Bugzilla when the associated issues on GitHub are closed.

Vladimir has already done some preliminary work on dlang-bot. I still need to get with him to discuss the process to ensure we handle it the right way and are prepared for all of the post-migration steps we need to take.

On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

Great work!

That might mean a long paragraph would appear as a really long line that has to be horizontally scrolled to read it.

Great!

OK, so we continue using bugzilla for each issue until we see that comment? With the rate limit gone, I'm guessing it shouldn't take too long.

Will the issues forum get github updates for new issues, status updates and comments?

So will dlang-bot close a matching github issue as well as the bugzilla one? Can PRs made after the migration just use e.g. Fixes #123 and dlang-bot will be able to find any corresponding bugzilla issue?

Thanks to everyone working on this. Looking forward to formatting in issue comments, better mobile UX (no more tiny text), better issue searching, better integration with github projects, issue link tooltips etc.

On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

Can we maybe have an automatic assessment if the comment happens to be Markdown already and if so, just use it?

Being aware of the transition, I filed issues and commented in Markdown syntax.

On Wednesday, 5 July 2023 at 13:54:17 UTC, Quirin Schroll wrote:

Same.

Issues with markdown code blocks in them will break when you nest them inside another markdown code block.

On Wednesday, 5 July 2023 at 14:01:16 UTC, Dennis wrote:

We can use indentation for the code blocks instead of fencing to avoid this problem.

On 7/5/23 10:01 AM, Dennis wrote:

I use markdown for code blocks in bugzilla not because of the transition, but because it's clear even when markdown isn't enabled.

three-backticks + language is pretty obvious and universal.

Granted, I'm used to reading all this markdown without the formatting in Thunderbird, and this is why I think markdown is a great mechanism -- it's pretty nice when it's properly formatted, and it also is readable when it's not.

-Steve

On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

This might cause a lot of notifications for people who file/comment a lot of bugs. It would probably swamp any important normal notifications for regular contributors that could get lost in the sea of bugzilla migration notifications.

On 7/5/23 12:01 PM, Nick Treleaven wrote:

Being tagged means you will get further notifications for new comments on the bug report. How does it work if you aren't tagged?

I think it would be pretty easy to announce when the migration is happening, and you just delete all the messages on that day.

-Steve

On Wednesday, 5 July 2023 at 16:11:20 UTC, Steven Schveighoffer wrote:

Yes, it's fine. In theory using a separate GitHub project just for issues would keep them from mixing in with dmd, Phobos notifications etc but that's only solving a temporary issue when having separate issues for each project is the better way to do it.

I just use the website notifications, but perhaps they can be searched to filter out the migration notifications.

On Wednesday, 5 July 2023 at 09:36:38 UTC, Nick Treleaven wrote:

Fortunately, Bugzilla pre-wraps comments at posting time, so this should not be an issue.

An exception is quoted text, which is not wrapped. You may notice that it can look misformatted on Bugzilla too.

No. Is that desired? I think this was done mainly because 1) the issues group predates Bugzilla, so Bugzilla reposting there was done for the benefit of that transition 2) Bugzilla is not searchable (it has a robots.txt rejecting all crawlers).

I think GitHub will close GitHub issues by itself if you say that a PR fixes some issue in the PR.

I think we would need to decide to either keep GitHub and Bugzilla in sync (to whatever extent, including the "open"/"closed" state), or make Bugzilla readonly, but we can't do both.