www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bugzilla to GitHub Continued

reply Mike Parker <aldacron gmail.com> writes:
After [the discussion in the forums regarding the 
migration](https://forum.dlang.org/post/pfpoeaoihsqpohumjvsi forum.dlang.org),
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.
Jul 04 2023
next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

 * 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


Great work!


 * text from Bugzilla will be posted to GitHub in Markdown code 
 blocks to avoid formatting issues


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


 * GitHub labels will be created from Bugzilla keywords and 
 applied to the new GitHub issues as appropriate


Great!


 * 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


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.


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


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


 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.


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. 

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.
Jul 05 2023
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 5 July 2023 at 09:36:38 UTC, Nick Treleaven wrote:

 * text from Bugzilla will be posted to GitHub in Markdown code 
 blocks to avoid formatting issues


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


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.


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


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


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).


 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.


 So will dlang-bot close a matching github issue as well as the 
 bugzilla one?


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



 dlang-bot will be able to find any corresponding bugzilla issue?


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.
Jul 05 2023
prev sibling next sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

 * text from Bugzilla will be posted to GitHub in Markdown code 
 blocks to avoid formatting issues


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.
Jul 05 2023
parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 5 July 2023 at 13:54:17 UTC, Quirin Schroll wrote:

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


Same.

Issues with markdown code blocks in them will break when you nest 
them inside another markdown code block.
Jul 05 2023
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 5 July 2023 at 14:01:16 UTC, Dennis wrote:

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

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


 Same.

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


We can use indentation for the code blocks instead of fencing to 
avoid this problem.
Jul 05 2023
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/5/23 10:01 AM, Dennis wrote:

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

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


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


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
Jul 05 2023
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 5 July 2023 at 14:01:16 UTC, Dennis wrote:

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


This seems to be a common myth. Robert ran into the same issue.

For fenced code blocks, you just have to use one more `` ` `` 
character for your fence than however long the longest string of 
`` ` `` characters is in the text you're trying to fence.

For example, if you have some text that already has ```` ``` 
````, you just wrap it in ````` ```` `````. (Yeah, I had to use 
five to write that just now!)

Example (log in and click "view source" to see the Markdown):

````
This is a bug. Reproducer:
```
void main() { int i = 0/0; }
```
More bug text goes here.
````

And of course there's also the original indentation method.
Jul 05 2023
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Tuesday, 4 July 2023 at 10:34:44 UTC, Mike Parker wrote:

 * the author of each issue and everyone on the CC list will 
 have their GitHub handles ` ` tagged in the initial comment


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.
Jul 05 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/5/23 12:01 PM, Nick Treleaven wrote:

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

 * the author of each issue and everyone on the CC list will have their 
 GitHub handles ` ` tagged in the initial comment


 
 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.


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
Jul 05 2023
parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 5 July 2023 at 16:11:20 UTC, Steven Schveighoffer 
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?


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 think it would be pretty easy to announce when the migration 
 is happening, and you just delete all the messages on that day.


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