RFC: Switching from Bugzilla to Github Issues [UPDATED]

Please reply to this proposal with your questions, comments, praise, or concerns.

I think it’s by and large a good plan, but I’d consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.).

In a previous mail on this thread there was the proposal for a “bait-and-switch” style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project.

I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the “-project” suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while.

Best regards
H.

I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect.

While I haven’t performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn’t expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests.

Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues).

I’m also going to add an additional concern/question I haven’t seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I’ve seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues – this seems notably undesirable. (The “bait-and-switch” tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported)

Best,

Wyatt

Please reply to this proposal with your questions, comments, praise, or concerns.

I think it's by and large a good plan, but I'd consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.).

In a previous mail on this thread there was the proposal for a "bait-and-switch" style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project.

I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the "-project" suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while.

I've asked the GitHub developers about the consequences of deleting and
renaming another repo, so we'll see what they say.

The llvm/llvm repo name was rejected during the conversion. llvm-project
was the name of the svn repo already so there was some consistency here,
and it also avoided having too many redundant llvm's which seemed confusing.

-Tom

I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect.

While I haven't performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn't expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests.

Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues).

I'm also going to add an additional concern/question I haven't seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I've seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues -- this seems notably undesirable. (The "bait-and-switch" tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported)

Someone else also mentioned this to me off-list. We don't have a good solution
for this right now other than asking people to turn off notifications, but
we'll continue to look into this.

-Tom

Tom,

Followed up on this quickly with some friends who recently imported an issue tracker of a few thousand issues. It seems github has an (undocumented? -- I haven't been able to find any documentation) API for this. I'm not sure how it was found, and the script they used is in written in little known scripting language (MethodScript), however, it's reasonably decipherable:
https://github.com/LadyCailin/YoutrackToGithubIssues/blob/master/procs.ms#L224

I'm sure reaching out to github, one could get further information; I suppose the important point here, is there does exist a means to import without sending many emails to subscribers.

Best,

Wyatt

We are trying to do our best to reach GitHub and asking how the issues
should be addressed. Unfortunately, as I already said, they are not
very responsive as they used to be during the repo migration. This
adds another complication, e.g. whether we have to wait for their
response (= indefinitely) or try some workaround.

Currently I'm playing with some workarounds here and there to see if
we could progress further w/o their help.

Hi,

I think this is the API "documented" (rather: described) here:
https://gist.github.com/jonmagic/5282384165e0f86ef105
If yes, also have a look at https://github.com/nijel/sf2gh which is a
Python script to migrate from SourceForge to GitHub.

Hope this helps,
Jonas