<div dir="ltr"><div>Thanks for writing this up! I can also confirm that I was there and it's accurate to my memory.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 24, 2019 at 7:55 PM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>We do <i>not</i> 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:</div><div>- You can subscribe to notification emails for activity in the entire llvm-project repository.</div><div>- You can subscribe to notification emails on an individual issue.</div><div>- Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).</div><div>- No emails will be sent to <a href="mailto:llvm-bugs@llvm.org" target="_blank">llvm-bugs@llvm.org</a> for github issues.</div><div>- 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).</div></div></div></div></blockquote><div><br></div><div>I wanted to say a bit to support the direction of not setting up a new whole-project notification system to replace llvm-bugs@.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Possibility 1: Migrate <i>all</i> 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.</div><div><br></div><div><div>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.<br></div><div><br></div><div></div></div><div>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 <i>preserve</i> the entire archive of existing bugs, but would not import the entire set into the "llvm-project" github repository.</div></div></div></div></blockquote><div> </div><div>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.<br></div><div><br></div><div><div>I'll also mention the <a href="http://llvm.org/pr*">llvm.org/pr*</a> link scheme. We should probably make those perma-links.</div><div></div></div></div></div>