[llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Reid Kleckner via llvm-dev]

Thanks for writing this up! I can also confirm that I was there and it's
accurate to my memory.

On Thu, Oct 24, 2019 at 7:55 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> We do *not* want to build supplementary notification systems to make
> github issues send additional emails that it is unable to send itself. We
> will only support what GitHub supports. That means:
> - You can subscribe to notification emails for activity in the entire
> llvm-project repository.
> - You can subscribe to notification emails on an individual issue.
> - Someone else can CC you on an individual issue to get your attention,
> and you will get notifications from that (unless you opt-out).
> - No emails will be sent to llvm-bugs at llvm.org for github issues.
> - There is no builtin way for users to subscribe to emails for bugs that
> have a given label (for example, all "clang" issues, or all x86 issues).
>

I wanted to say a bit to support the direction of not setting up a new
whole-project notification system to replace llvm-bugs at .

LLVM as a project is much bigger than it was when llvm-bugs@ was created.
These days, new developers do not generally subscribe to llvm-bugs@, and if
they do, they don't use it to triage issues. What happens in practice is
that we have a subset of developers who do triage, add the component, and
CC individuals who know the code in question. We don't need a single
mailing list for all bugs to replicate this process. We could instead
document a process of triage, where triagers periodically run a search to
find issues without tags and then apply tags and CCs as we do today. We
could formalize this with a rotation, but let's not get ahead of ourselves.

I really would love to find a way to get email notifications from a
specific issue tag, but I don't want to block opening the new tracker on
that. Until we find a solution to that, we'll have to get used to
refreshing a bookmarked search for our favorite tags. I recall that this
was discussed during the round table, and people generally agreed that new
users being able to find bugs was more important than a good subscription
system.

Possibility 1: Migrate *all* the existing bugs into a secondary
> "llvm-bugs-archive" github repository, and then turn off bugzilla. Github
> offers the ability to move bugs from one repository to another, and so we
> can use this to move bugs that are still relevant afterwards (potentially
> this could be done automatically upon any activity). Then, shut down
> bugzilla, and leave behind only a redirect script.
>
> Possibility 2: Create the ability to import an individual bug from
> Bugzilla into the llvm-project repository by pressing a "migrate this bug
> to github" button. Then, leave bugzilla running only as a static snapshot
> -- as static as possible while leaving the "migrate this bug to github"
> button operational.
>
> In both cases, we'd want to support a redirect script to take you from the
> old bug ids to the migrated bug page. In both cases, we would *preserve*
> the entire archive of existing bugs, but would not import the entire set
> into the "llvm-project" github repository.
>

I guess "possibility 1" seems like the best to me. Once we get a good
backup of all the data, it lets us turn off bugzilla sooner. It also seems
easier since there are probably existing scripts to do this that we can
reuse.

I'll also mention the llvm.org/pr* link scheme. We should probably make
those perma-links.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191025/bad8f8b4/attachment.html>