We are considering moving from Bugzilla to GitHub issues as well. One argument in favor of the migration is to reduce the barrier for would-be bug reporters, as they may give up due to needing to create a new account or using an unfamiliar UI. However, this is something that is difficult to measure unless we perform the migration and compare the before and after.
So, I’m curious if the LLVM project has noticed any change. Has the quantity or quality of issues reported on the project’s GitHub org changed, compared to Bugzilla?
I can’t answer your question, but I’d like to note that formatting hasn’t survived this migration. When I look at migrated bugs, I always skip to read-only bugzilla instance, because formatting there is much more sane that what you see on GitHub.
One of the major advantages of using GitHub issues is that we’ve been able to automate a lot more of our processes. For example, for releases, we now have an automated flow where someone can request a fix be backported to the release branch with a simple comment like /cherry-pick abcdef When we were using bugzilla, when a backport request came in, the release manager would have to:
cherry-pick the commit locally.
Notify the requester if the cherry-pick failed.
Build and test the backport locally.
Notify the requester of any build or test failures.
Find a reviewer for the backport and ask them to review it.
Now this is all automated and it creates a much better experience for the release managers and the users.
This is a nice improvement, but it seems to me that you could have used GitHub issues (or any other automation) for managing the cherry-picking of commits independently of migrating from Bugzilla for bug tracking in general, it’s not clear to me that the two are highly coupled.