[llvm-dev] RFC: Switching from Bugzilla to Github Issues
James Y Knight via llvm-dev
David Blaikie via llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
James Y Knight via llvm-dev
Tim Northover via llvm-dev
Good write-up, and I'm in favour.
One other thing I remembered from the round-table was that I think we
did talk about extending e-mail CC flexibility as a future goal.
Chandler mentioned there may well even be off the shelf solutions we
could use that integrate with GitHub, but no-one spoke up saying that
should block the initial proposed activation in 2 weeks.
Cheers.
Tim.
JF Bastien via llvm-dev
Martin Storsjö via llvm-dev
> 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).
bisecting a regression and filing a bug with the reproducer, I try to add
CCs for the author of the commit and potentially the reviewers who were
involved with the commit.
In bugzilla it's fairly easy to try type people's names (which you find
easily via the Phabricator review) and bugzilla will autocomplete and let
you pick whoever seems to match what you typed.
In github I'd presume you need to know the github username of the ones you
want to CC. For the cases where it matches the Phabricator username, this
is straightforward, but I'm sure there's a significant number of users
where the mapping isn't obvious.
After filing a regression bug I normally link to it from the originating
review thread as well, which hopefully serves as notification to the same
people as well though. (But depending on mail sorting habits and use of
Phabricator, where e.g. I normally only list open reviews, it can be easy
to miss a comment on a closed review).
// Martin
Mehdi AMINI via llvm-dev
We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.Most of the ideas here were from other people. I believe this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
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.
Anton Korobeynikov via llvm-dev
scripts for this) it also relies on lots of things fully done, e.g.
the list of all tags for us to build the mapping from e.g. components
to tags, etc.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
Martin Storsjö via llvm-dev
> On Thu, 24 Oct 2019, James Y Knight via llvm-dev 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).
>
> One thing comes to mind wrt workflows and how I often use bugzilla: After
> bisecting a regression and filing a bug with the reproducer, I try to add CCs
> for the author of the commit and potentially the reviewers who were involved
> with the commit.
>
> In bugzilla it's fairly easy to try type people's names (which you find
> easily via the Phabricator review) and bugzilla will autocomplete and let you
> pick whoever seems to match what you typed.
>
> In github I'd presume you need to know the github username of the ones you
> want to CC. For the cases where it matches the Phabricator username, this is
> straightforward, but I'm sure there's a significant number of users where the
> mapping isn't obvious.
github, github is actually very good at replacing any references to the
original author name with their github username (to the extent that it
actually is hard to find the realname of the author when viewing a
commit).
So for CCing people on issues, the author/committer should be easy to
discover; potential related reviewers are the only ones where discovering
their github usernames might be tricky. And that's much less important.
// Martin
Finkel, Hal J. via llvm-dev
I disagree, this is extremely important. Many bugs are filed by people who don't know what commit is relevant, and other community members who watch the bugs list (including myself) help cc the right people. We must have a straightforward way to cc people. A list somewhere with people's names could be a fine solution, but the current autocomplete is an important part of the workflow, and a limited search is important (as I often don't remember exactly how various people's names are spelled).
-Hal
// Martin
_______________________________________________ LLVM Developers mailing list llvm...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
Shoaib Meenai via llvm-dev
In my experience, when you start typing @ in a GitHub comment, it brings up an autocomplete with tagging suggestions, and that autocomplete works for both usernames and real names (assuming people have their name on their GitHub account).
Reid Kleckner via llvm-dev
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...@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).
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.
Robinson, Paul via llvm-dev
> - 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).
Last year Kristof Beyls and I did a BoF on bug handling, and my memory is that a nonzero number of people were willing to be auto-CC'd on particular topics but did not want to subscribe to llvm-bugs. This description of the github tracker means that would not be feasible, which is a step backwards.
I can anticipate a counter-argument which is that someone can easily search for bugs with particular tags. I claim that's not equivalent, because it requires action on the part of the person to go look for things, and that happens only when the person thinks of doing it. Computers should automate the tedious parts, like alerting the people who are interested in issues with a particular tag.
--paulr
Philip Reames via llvm-dev
Generally supportive here, but I see a couple of small concerns.
We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
Most of the ideas here were from other people. I believe this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
Background----
Our bugzilla installation is...not great. It's been not-great for a long time now.
Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org's fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating whether we should switch, we discussed how we should switch. And came up with a plan to switch quickly.
GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
Proposal----We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
Some things we'd like to get in place before turning on Github's Issue tracker:1. Updated documentation.2. An initial set of issue tags we'd like to use for triaging/categorizing issues.3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
But more important are the things we do not want to make prerequisites for turning on Github issues:
We do not yet plan to turn off Bugzilla, and do not plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
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...@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).
The last two items are *very* unfortunate. A quick skim through the API documentation (https://developer.github.com/v3/issues/) would seem to indicate implementing these fairly straight forward. I think it might be worth implementing our own custom scripts here.
I'm legitimately torn as to whether this should be considered a blocker. I don't actually use either method, so my personal vote is no, but I believe others do. Breaking existing workflows when relatively little effort is required not to seems less than idea.
Further steps----After we migrate, there's still things we want to do:
1. Discuss and setup new and better procedures around bug triage and prioritization.
What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
2. Bug migration
After the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
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.
Sachkov, Alexey via llvm-dev
There are 4 levels:
- ignore all notifications including @mention
- notification on @mention or if participating (left a comment, owner of issue/PR)
- notification on releases + previous item
- get notification about *all* activity: every update in every issue/PR
However, there is such thing as teams: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-teams
We could create teams for front-end, back-ends, static analyzer and all other components to quickly summon all potentially interested people.
-----Original Message-----
From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Robinson, Paul via llvm-dev
Sent: Friday, October 25, 2019 9:35 PM
To: James Y Knight <jykn...@google.com>; 'llvm...@lists.llvm.org' <llvm...@lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Switching from Bugzilla to Github Issues
--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Anton Korobeynikov via llvm-dev
> 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.
unfortunately. The current list of questions / issues could be found
at https://docs.google.com/document/d/1byEcbsxF3pL-HGGd_K6axdh87tbcsuJK3Dp6ThxGjKA
– please comment.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
Kristof Beyls via llvm-dev
My 2 cents to add (which I forgot at the round table) is that in general, we probably do a poor job at triaging or acknowledging new bugs that are being raised. There are some exceptions though, for some components, where a few people very actively triage and acknowledge new bug reports. I'd hate to see this disappear. Therefore, I think it's important for people to be able to continue to easily filter updates to bugs based on components and/or keyword - so that the few that are currently motivated and perform a lot of bug triage keep on doing so - by enabling a high signal-to-noise ratio in github issue notifications for them.
I'm not sure if this is easy to do with github issues (I don't think I saw ideal solutions being described in the thread above). Maybe getting all notification emails from all bugs, and then being able to filter it client-side based on keywords will work well enough, I don't know.
James Henderson via llvm-dev
> - 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 mailto:llvm...@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).
That last is really unfortunate. Someone only interested in (say) LLDB issues would have to subscribe to all notifications and hope that there are enough breadcrumbs in a new issue to be able to do accurate email filtering. It would be better to handle this in the bug tracker itself.
Last year Kristof Beyls and I did a BoF on bug handling, and my memory is that a nonzero number of people were willing to be auto-CC'd on particular topics but did not want to subscribe to llvm-bugs. This description of the github tracker means that would not be feasible, which is a step backwards.
I can anticipate a counter-argument which is that someone can easily search for bugs with particular tags. I claim that's not equivalent, because it requires action on the part of the person to go look for things, and that happens only when the person thinks of doing it. Computers should automate the tedious parts, like alerting the people who are interested in issues with a particular tag.
--paulr
Joseph Tremoulet via llvm-dev
-Joseph
[1] https://help.github.com/en/github/receiving-notifications-about-activity-on-github/about-email-notifications#filtering-email-notifications
[apologies to those of you receiving this twice; my mail client likes to drop llvm-dev from reply-all for some reason...]
-----Original Message-----
From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Sachkov, Alexey via llvm-dev
Sent: Saturday, October 26, 2019 12:41 PM
To: Robinson, Paul <paul.r...@sony.com>; James Y Knight <jykn...@google.com>; llvm...@lists.llvm.org
Subject: Re: [llvm-dev] RFC: Switching from Bugzilla to Github Issues
There are 4 levels:
- ignore all notifications including @mention
- notification on @mention or if participating (left a comment, owner of issue/PR)
- notification on releases + previous item
- get notification about *all* activity: every update in every issue/PR
However, there is such thing as teams: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-teams
We could create teams for front-end, back-ends, static analyzer and all other components to quickly summon all potentially interested people.
-----Original Message-----
From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Robinson, Paul via llvm-dev
Sent: Friday, October 25, 2019 9:35 PM
To: James Y Knight <jykn...@google.com>; 'llvm...@lists.llvm.org' <llvm...@lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Switching from Bugzilla to Github Issues
> - You can subscribe to notification emails for activity in the entire llvm-project repository.
Is that only new issues? Or all activity? If it's all activity on all issues, you're effectively auto-subscribing to all issues, and really nobody would want that. Well, maybe, like, 3 people.
> - 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 mailto:llvm...@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).
That last is really unfortunate. Someone only interested in (say) LLDB issues would have to subscribe to all notifications and hope that there are enough breadcrumbs in a new issue to be able to do accurate email filtering. It would be better to handle this in the bug tracker itself.
Last year Kristof Beyls and I did a BoF on bug handling, and my memory is that a nonzero number of people were willing to be auto-CC'd on particular topics but did not want to subscribe to llvm-bugs. This description of the github tracker means that would not be feasible, which is a step backwards.
I can anticipate a counter-argument which is that someone can easily search for bugs with particular tags. I claim that's not equivalent, because it requires action on the part of the person to go look for things, and that happens only when the person thinks of doing it. Computers should automate the tedious parts, like alerting the people who are interested in issues with a particular tag.
--paulr
Tom Stellard via llvm-dev
>> Is that only new issues? Or all activity? If it's all activity on all issues, you're effectively auto-subscribing to all issues, and really nobody would want that. Well, maybe, like, 3 people.
>
> Looking at docs for notification: https://help.github.com/en/github/receiving-notifications-about-activity-on-github/about-notifications#types-of-notifications
>
> There are 4 levels:
> - ignore all notifications including @mention
> - notification on @mention or if participating (left a comment, owner of issue/PR)
> - notification on releases + previous item
> - get notification about *all* activity: every update in every issue/PR
>
> However, there is such thing as teams: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-teams
>
> We could create teams for front-end, back-ends, static analyzer and all other components to quickly summon all potentially interested people.
>
With teams we can easily create a GitHub action to auto-subscribe all team
members when a new label is added to an issue, so I think using teams is
a good option.
-Tom
Tom Stellard via llvm-dev
> We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
>
>
>
> Background
> ----
> Our bugzilla installation is...not great. It's been not-great for a long time now.
>
>
> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>
> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>
>
> Proposal
> ----
> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>
I think we need a gap between when we turn on issues and when we tell people to
start using it, so that we can get some kind of notification system in place.
I think this may also address some concerns people have had with this proposal.
What about if we turn issues on in 1 week and then only start telling people
to use it for new bugs once we have a decent notification system working?
> Some things we'd like to get in place before turning on Github's Issue tracker:
> 1. Updated documentation.
> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
Here are my suggestions for the minimal set of tags:
+ 1 per LLVM backend
+ 1 per top-level directory in https://github.com/llvm/llvm-project
I think if we start here we can create more specialized tags as
GitHub issues gets more traffic and we have more experience using it.
-Tom
> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>
> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>
> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>
> 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...@llvm.org <mailto:llvm...@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).
>
> Further steps
> ----
> After we migrate, there's still things we want to do:
>
> 1. Discuss and setup new and better procedures around bug triage and prioritization.
>
> What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
>
> 2. Bug migration
>
> /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
>
> 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.
Anton Korobeynikov via llvm-dev
>
> + 1 per LLVM backend
> + 1 per top-level directory in https://github.com/llvm/llvm-project
>
> I think if we start here we can create more specialized tags as
> GitHub issues gets more traffic and we have more experience using it.
components. It could be used as a good starting point for defining a
list of tags.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
James Henderson via llvm-dev
Tom Stellard via llvm-dev
> +1 to using Anton's list as a starting point. I think the top-level directories llvm-project + backends are not really fine-grained enough for some areas. For example, the code related to the various LLVM binary utilities like llvm-readobj/llvm-objcopy/llvm-symbolizer etc is all contained within llvm/tools, and wouldn't have their own tag, or even one closely related ("llvm" would be the tag they'd come under, which is... less than useful). Separate tags for each tool (possibly with some shared ones for tools which are broadly aliases like llvm-objcopy/llvm-strip and llvm-readelf/llvm-readobj etc) would certainly help me. Bugzilla already has most of these.
>
I agree with you that my list is not fine-grained enough. I just think it would
be better to add tags as we go rather than copying the current list from bugzilla
and have a lot of tags that we don't need. However, if you think having tags
for the tools would be useful, I would be fine with adding those initially.
Can you write a list of all the specific tags you would like.
-Tom
> On Mon, 28 Oct 2019 at 23:11, Anton Korobeynikov via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>
> > Here are my suggestions for the minimal set of tags:
> >
> > + 1 per LLVM backend
> > + 1 per top-level directory in https://github.com/llvm/llvm-project
> >
> > I think if we start here we can create more specialized tags as
> > GitHub issues gets more traffic and we have more experience using it.
> The google doc I created contains the slightly cleaned list of current
> components. It could be used as a good starting point for defining a
> list of tags.
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
James Henderson via llvm-dev
Tom Stellard via llvm-dev
>
>
>
Hi,
I want to restart this discussion. There seemed to be support for this,
but we got held up trying to decide on the appropriate set of tags to
use to classify issues.
I propose that we move forward with this proposal and disable creation of
new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
issues from that date forward.
I think that for choosing the tags to use, we should just take requests
from the community over the next week and add whatever is asked for. The main
purpose of adding tags is so we can setup cc lists for bugs, so I think this
is a good way to ensure that we have tags people care about. We can always
add more tags later if necessary.
What does everyone think about this?
-Tom
> Background
> ----
> Our bugzilla installation is...not great. It's been not-great for a long time now.
>
> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
>
> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>
> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>
>
> Proposal
> ----
> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>
> Some things we'd like to get in place before turning on Github's Issue tracker:
> 1. Updated documentation.
> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>
> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>
> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>
> 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...@llvm.org <mailto:llvm...@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).
>
> Further steps
> ----
> After we migrate, there's still things we want to do:
>
> 1. Discuss and setup new and better procedures around bug triage and prioritization.
>
> What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
>
> 2. Bug migration
>
> /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
>
> 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.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
Aaron Ballman via llvm-dev
<cfe...@lists.llvm.org> wrote:
>
> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
> >
> > Most of the ideas here were from other people. I /believe/ this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
> >
> >
>
> Hi,
>
> I want to restart this discussion. There seemed to be support for this,
> but we got held up trying to decide on the appropriate set of tags to
> use to classify issues.
>
> I propose that we move forward with this proposal and disable creation of
> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
> issues from that date forward.
>
> I think that for choosing the tags to use, we should just take requests
> from the community over the next week and add whatever is asked for. The main
> purpose of adding tags is so we can setup cc lists for bugs, so I think this
> is a good way to ensure that we have tags people care about. We can always
> add more tags later if necessary.
>
> What does everyone think about this?
What did we decide to do with all the existing issues in Bugzilla?
~Aaron
> cfe-dev mailing list
> cfe...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Tom Stellard via llvm-dev
> On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> <cfe...@lists.llvm.org> wrote:
>>
>> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
>>> We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
>>>
>>> Most of the ideas here were from other people. I /believe/ this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
>>>
>>>
>>
>> Hi,
>>
>> I want to restart this discussion. There seemed to be support for this,
>> but we got held up trying to decide on the appropriate set of tags to
>> use to classify issues.
>>
>> I propose that we move forward with this proposal and disable creation of
>> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
>> issues from that date forward.
>>
>> I think that for choosing the tags to use, we should just take requests
>> from the community over the next week and add whatever is asked for. The main
>> purpose of adding tags is so we can setup cc lists for bugs, so I think this
>> is a good way to ensure that we have tags people care about. We can always
>> add more tags later if necessary.
>>
>> What does everyone think about this?
>
> What did we decide to do with all the existing issues in Bugzilla?
>
This is undecided. The first step of this proposal only affects new issues.
Existing issues will remain in bugzilla and will be updated there too. At
some point in the future bugzilla will become read-only and/or the issues will
be migrated somewhere else, but no decision has been made about how to do that yet.
-Tom
Aaron Ballman via llvm-dev
Mehdi AMINI via llvm-dev
On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
>
> Most of the ideas here were from other people. I /believe/ this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
>
>
Hi,
I want to restart this discussion. There seemed to be support for this,
but we got held up trying to decide on the appropriate set of tags to
use to classify issues.
I propose that we move forward with this proposal and disable creation of
new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
issues from that date forward.
I think that for choosing the tags to use, we should just take requests
from the community over the next week and add whatever is asked for. The main
purpose of adding tags is so we can setup cc lists for bugs, so I think this
is a good way to ensure that we have tags people care about. We can always
add more tags later if necessary.
Tom Stellard via llvm-dev
> Hi,
>
>
>
>
> On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>> wrote:
>
> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
> >
> > Most of the ideas here were from other people. I /believe/ this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
> >
> >
>
> Hi,
>
> I want to restart this discussion. There seemed to be support for this,
> but we got held up trying to decide on the appropriate set of tags to
> use to classify issues.
>
> I propose that we move forward with this proposal and disable creation of
> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
> issues from that date forward.
>
> I think that for choosing the tags to use, we should just take requests
> from the community over the next week and add whatever is asked for. The main
> purpose of adding tags is so we can setup cc lists for bugs, so I think this
> is a good way to ensure that we have tags people care about. We can always
> add more tags later if necessary.
>
>
> Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>
When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.
From what I can tell, there are a couple different ways to auto-subscribe
people using github actions. I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.
I was planning to experiment more with this over the next few days.
-Tom
> --
> Mehdi
>
>
>
>
>
>
> What does everyone think about this?
>
> -Tom
>
>
> > Background
> > ----
> > Our bugzilla installation is...not great. It's been not-great for a long time now.
> >
> > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
> >
> > This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
> >
> > GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
> >
> >
> > Proposal
> > ----
> > We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
> >
> > Some things we'd like to get in place before turning on Github's Issue tracker:
> > 1. Updated documentation.
> > 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
> >
> > But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
> >
> > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
> >
> > 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...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@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).
> >
> > Further steps
> > ----
> > After we migrate, there's still things we want to do:
> >
> > 1. Discuss and setup new and better procedures around bug triage and prioritization.
> >
> > What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
> >
> > 2. Bug migration
> >
> > /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
> >
> > 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.
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Sean McBride via llvm-dev
>> What does everyone think about this?
>
>What did we decide to do with all the existing issues in Bugzilla?
Will you be able to start numbering in github at a number larger than the largest bug in bugzilla? It would be annoying to have overlapping bug numbers. Bug numbers exist in code comments, list archives, etc., etc. If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.
Sean
Jacob Lifshay via llvm-dev
Hi,
I want to restart this discussion. There seemed to be support for this,
but we got held up trying to decide on the appropriate set of tags to
use to classify issues.
I propose that we move forward with this proposal and disable creation of
new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
issues from that date forward.
I think that for choosing the tags to use, we should just take requests
from the community over the next week and add whatever is asked for. The main
purpose of adding tags is so we can setup cc lists for bugs, so I think this
is a good way to ensure that we have tags people care about. We can always
add more tags later if necessary.
What does everyone think about this?
David Major via llvm-dev
Anton Korobeynikov via llvm-dev
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
folks knows about this issue and planned to work on them, but there
was no ETA on this.
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
Anton Korobeynikov via llvm-dev
of PRs and issues opened... And github uses consecutive numbering for
all PRs, issues and such... So, there is already overlap here.
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
Anton Korobeynikov via llvm-dev
wrote:
>
> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev wrote:
>>
>> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> >>>
>> >>> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>> >>>
>> >>> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>> >>>
>> >>>
>> >>> Proposal
>> >>> ----
>> >>> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>> >>>
>> >>> Some things we'd like to get in place before turning on Github's Issue tracker:
>> >>> 1. Updated documentation.
>> >>> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
>> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>> >>>
>> >>> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>> >>>
>> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>> >>>
>> >>> 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).
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
James Henderson via llvm-dev
Tom Stellard via llvm-dev
> My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.
>
Would you be able to help me test some potential solutions for this?
-Tom
> > > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
> > >
> > > This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
> > >
> > > GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
> > >
> > >
> > > Proposal
> > > ----
> > > We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
> > >
> > > Some things we'd like to get in place before turning on Github's Issue tracker:
> > > 1. Updated documentation.
> > > 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> > > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
> > >
> > > But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
> > >
> > > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
> > >
> > > 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...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@llvm.org>> <mailto:llvm...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@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).
> > >
> > > Further steps
> > > ----
> > > After we migrate, there's still things we want to do:
> > >
> > > 1. Discuss and setup new and better procedures around bug triage and prioritization.
> > >
> > > What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
> > >
> > > 2. Bug migration
> > >
> > > /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
> > >
> > > 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.
> > >
> > >
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
Fangrui Song via llvm-dev
>On 01/31/2020 01:21 AM, James Henderson wrote:
>> My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.
>>
>
>Would you be able to help me test some potential solutions for this?
My feeling is similar to James'.
+1 if auto subscription is available (similar to Herald rules).
-1 if it isn't.
And I guess contributors may need to change the notification setting from "Watching" to "Not watching",
to avoid issue spam.
Tom, I'd like to be a tester.
Fangrui Song via llvm-dev
>> Will you be able to start numbering in github at a number larger than the largest bug in bugzilla? It would be annoying to have overlapping bug numbers. Bug numbers exist in code comments, list archives, etc., etc. If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.
>This won't work in general, unfortunately as there are already a bunch
>of PRs and issues opened... And github uses consecutive numbering for
>all PRs, issues and such... So, there is already overlap here.
It'd be nice if Github allows to bump the issue counter to 44000+ .
(current largest https://bugs.llvm.org/show_bug.cgi?id= id is 44000+)
Then the website can set up a redirector:
http://llvm.org/PR1 => https://bugs.llvm.org/show_bug.cgi?id=1
...
http://llvm.org/PR44000 => https://bugs.llvm.org/show_bug.cgi?id=44000
...
http://llvm.org/PR45000 => https://github.com/llvm/llvm-project/issue/45000
http://llvm.org/PR50000 => https://github.com/llvm/llvm-project/issue/50000
Anton Korobeynikov via llvm-dev
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
James Henderson via llvm-dev
Michael Kruse via llvm-dev
<cfe...@lists.llvm.org>:
This adds a burden on everyone to observe two locations for bugs. By
comparison creating a GitHub account is simple. Even creating a
bugzilla account is more difficult.
Michael
Jacob Lifshay via llvm-dev
Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev
<cfe...@lists.llvm.org>:
>
> On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I want to restart this discussion. There seemed to be support for this,
>> but we got held up trying to decide on the appropriate set of tags to
>> use to classify issues.
>>
>> I propose that we move forward with this proposal and disable creation of
>> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
>> issues from that date forward.
>>
>> I think that for choosing the tags to use, we should just take requests
>> from the community over the next week and add whatever is asked for. The main
>> purpose of adding tags is so we can setup cc lists for bugs, so I think this
>> is a good way to ensure that we have tags people care about. We can always
>> add more tags later if necessary.
>>
>> What does everyone think about this?
>
>
> Before disabling Bugzilla, I think there should be a way for those who don't have/want github accounts to create/comment-on bug reports (maybe a mailing list with a thread per bug?). Once that's done, I'm all for switching to github.
This adds a burden on everyone to observe two locations for bugs. By
comparison creating a GitHub account is simple. Even creating a
bugzilla account is more difficult.
Luke Kenneth Casson Leighton via llvm-dev
On Monday, February 3, 2020, Jacob Lifshay <program...@gmail.com> wrote:
---------- Forwarded message ---------
From: Jacob Lifshay <program...@gmail.com>
Date: Mon, Feb 3, 2020, 09:11
Subject: Re: [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
To: Michael Kruse <cfe...@meinersbur.de>
Cc: Tom Stellard <tste...@redhat.com>, llvm-dev <llvm...@lists.llvm.org>, LLDB Dev <lldb...@lists.llvm.org>, cfe-dev <cfe...@lists.llvm.org>On Mon, Feb 3, 2020, 09:00 Michael Kruse <cfe...@meinersbur.de> wrote:Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev
<cfe...@lists.llvm.org>:
>
> On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I want to restart this discussion. There seemed to be support for this,
>> but we got held up trying to decide on the appropriate set of tags to
>> use to classify issues.
>>
>> I propose that we move forward with this proposal and disable creation of
>> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
>> issues from that date forward.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Tom Stellard via llvm-dev
> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>
Yes, I think this makes sense, let's postpone until then.
-Tom
> >>> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
> >>>
> >>> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
> >>>
> >>> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
> >>>
> >>>
> >>> Proposal
> >>> ----
> >>> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
> >>>
> >>> Some things we'd like to get in place before turning on Github's Issue tracker:
> >>> 1. Updated documentation.
> >>> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
> >>>
> >>> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
> >>>
> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
> >>>
> >>> 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...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@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).
> >>>
> >>> Further steps
> >>> ----
> >>> After we migrate, there's still things we want to do:
> >>>
> >>> 1. Discuss and setup new and better procedures around bug triage and prioritization.
> >>>
> >>> What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
> >>>
> >>> 2. Bug migration
> >>>
> >>> /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Tom Stellard via llvm-dev
> On 01/30/2020 12:47 PM, David Major wrote:
>> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>>
>
> Yes, I think this makes sense, let's postpone until then.
>
Hi,
10.0.0-rc4 was just released, and I think we are at the point in the release cycle
where it is safe to begin the migration to GitHub issues.
I would like to propose doing the migration in one week (March 23). This means
making the existing bugzilla read-only, and updating the documentation to tell users
to file issues at GitHub. We are still trying to figure out the best way to import bugs
from bugzilla into GitHub, so this step will be done at a later date.
For the initial list of tags, I propose we generate the list based on the most commonly
used categories in bugzilla. This should be enough to get us started and we can always
add more tags as we go.
I've also implemented a notification system using GitHub actions that will make
it possible to subscribe to individual issue tags, so we would enable this on Monday
as well.
What does everyone think?
Thanks,
Tom
Aaron Ballman via llvm-dev
<cfe...@lists.llvm.org> wrote:
>
> On 02/10/2020 07:40 PM, Tom Stellard wrote:
> > On 01/30/2020 12:47 PM, David Major wrote:
> >> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
> >>
> >
> > Yes, I think this makes sense, let's postpone until then.
> >
>
> Hi,
>
> 10.0.0-rc4 was just released, and I think we are at the point in the release cycle
> where it is safe to begin the migration to GitHub issues.
>
> I would like to propose doing the migration in one week (March 23). This means
> making the existing bugzilla read-only, and updating the documentation to tell users
> to file issues at GitHub. We are still trying to figure out the best way to import bugs
> from bugzilla into GitHub, so this step will be done at a later date.
>
> For the initial list of tags, I propose we generate the list based on the most commonly
> used categories in bugzilla. This should be enough to get us started and we can always
> add more tags as we go.
>
> I've also implemented a notification system using GitHub actions that will make
> it possible to subscribe to individual issue tags, so we would enable this on Monday
> as well.
>
> What does everyone think?
I am uncomfortable switching to GitHub issues unless the initial
result is that we have ONE set of bugs to track (I do not want to have
to search and maintain separate bug lists). Moving bugs from Bugzilla
at an unspecified future time is a deal-breaker for me, so -1.
~Aaron
> cfe-dev mailing list
> cfe...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
Hubert Tong via llvm-dev
On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
> Hi,
>
> 10.0.0-rc4 was just released, and I think we are at the point in the release cycle
> where it is safe to begin the migration to GitHub issues.
>
> I would like to propose doing the migration in one week (March 23). This means
> making the existing bugzilla read-only, and updating the documentation to tell users
> to file issues at GitHub. We are still trying to figure out the best way to import bugs
> from bugzilla into GitHub, so this step will be done at a later date.
>
> For the initial list of tags, I propose we generate the list based on the most commonly
> used categories in bugzilla. This should be enough to get us started and we can always
> add more tags as we go.
>
> I've also implemented a notification system using GitHub actions that will make
> it possible to subscribe to individual issue tags, so we would enable this on Monday
> as well.
>
> What does everyone think?
I am uncomfortable switching to GitHub issues unless the initial
result is that we have ONE set of bugs to track (I do not want to have
to search and maintain separate bug lists). Moving bugs from Bugzilla
at an unspecified future time is a deal-breaker for me, so -1.
~Aaron
James Henderson via llvm-dev
On 02/10/2020 07:40 PM, Tom Stellard wrote:
> On 01/30/2020 12:47 PM, David Major wrote:
>> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>>
>
> Yes, I think this makes sense, let's postpone until then.
>
Hi,
10.0.0-rc4 was just released, and I think we are at the point in the release cycle
where it is safe to begin the migration to GitHub issues.
I would like to propose doing the migration in one week (March 23). This means
making the existing bugzilla read-only, and updating the documentation to tell users
to file issues at GitHub.
We are still trying to figure out the best way to import bugs
from bugzilla into GitHub, so this step will be done at a later date.
For the initial list of tags, I propose we generate the list based on the most commonly
used categories in bugzilla. This should be enough to get us started and we can always
add more tags as we go.
Tom Stellard via llvm-dev
>
>
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>> wrote:
>
> On 02/10/2020 07:40 PM, Tom Stellard wrote:
> > On 01/30/2020 12:47 PM, David Major wrote:
> >> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
> >>
> >
> > Yes, I think this makes sense, let's postpone until then.
> >
>
> Hi,
>
> 10.0.0-rc4 was just released, and I think we are at the point in the release cycle
> where it is safe to begin the migration to GitHub issues.
>
> I would like to propose doing the migration in one week (March 23). This means
> making the existing bugzilla read-only, and updating the documentation to tell users
> to file issues at GitHub.
>
>
> Don't forget to update the URL used in crash messages to point at the right location.
>
>
> We are still trying to figure out the best way to import bugs
> from bugzilla into GitHub, so this step will be done at a later date.
>
>
> Making bugzilla read-only seems like a bad idea until all existing issues have been migrated. What if people need to update an existing bug once the migration to using Github issues has happened before importing has also happened?
>
This was a mistake on my part. The plan is to disable creation of new bugs in bugzilla and not
to make it read-only. If you look at the original RFC, it says GitHub issues
would be used for new issues, and existing issues will continue to be updated in bugzilla,
and this is what I'm proposing.
>
>
> For the initial list of tags, I propose we generate the list based on the most commonly
> used categories in bugzilla. This should be enough to get us started and we can always
> add more tags as we go.
>
>
> I'd like this list to be fleshed out before migration is agreed. I'm concerned different people will have wildly different ideas of what "commonly used" might mean, which could in turn have an impact on the viability of this tag list.
>
Most commonly used here means categories with the most bugs. So, this would be
based on raw bug counts and not just someone's opinion.
-Tom
> >> >>> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
> >> >>>
> >> >>> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
> >> >>>
> >> >>> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
> >> >>>
> >> >>>
> >> >>> Proposal
> >> >>> ----
> >> >>> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
> >> >>>
> >> >>> Some things we'd like to get in place before turning on Github's Issue tracker:
> >> >>> 1. Updated documentation.
> >> >>> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> >> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
> >> >>>
> >> >>> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
> >> >>>
> >> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
> >> >>>
> >> >>> 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...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@llvm.org>> <mailto:llvm...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@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).
> >> >>>
> >> >>> Further steps
> >> >>> ----
> >> >>> After we migrate, there's still things we want to do:
> >> >>>
> >> >>> 1. Discuss and setup new and better procedures around bug triage and prioritization.
> >> >>>
> >> >>> What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
> >> >>>
> >> >>> 2. Bug migration
> >> >>>
> >> >>> /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> LLVM Developers mailing list
> >> >>> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >>>
> >> >>
> >> >> _______________________________________________
> >> >> cfe-dev mailing list
> >> >> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>
> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >> >
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
David Chisnall via llvm-dev
> This was a mistake on my part. The plan is to disable creation of new bugs in bugzilla and not
> to make it read-only. If you look at the original RFC, it says GitHub issues
> would be used for new issues, and existing issues will continue to be updated in bugzilla,
> and this is what I'm proposing.
Does this mean that we're giving up on aligning Bugzilla PRs with GitHub
issue numbers? This won't be possible once people have created issues /
PRs on GitHub. It looks as if we have a hundred or so PRs / issues
already, so maybe it's too late to think about this...
David
Hubert Tong via llvm-dev
On 16/03/2020 15:08, Tom Stellard via llvm-dev wrote:
> This was a mistake on my part. The plan is to disable creation of new bugs in bugzilla and not
> to make it read-only. If you look at the original RFC, it says GitHub issues
> would be used for new issues, and existing issues will continue to be updated in bugzilla,
> and this is what I'm proposing.
Does this mean that we're giving up on aligning Bugzilla PRs with GitHub
issue numbers? This won't be possible once people have created issues /
PRs on GitHub. It looks as if we have a hundred or so PRs / issues
already, so maybe it's too late to think about this...
James Henderson via llvm-dev
Anton Korobeynikov via llvm-dev
> issue numbers? This won't be possible once people have created issues /
> PRs on GitHub. It looks as if we have a hundred or so PRs / issues
> already, so maybe it's too late to think about this...
submitted a feature request, but there is neither ETA nor even any
information whether GitHub is willing to implement something that
would better suit our needs in migration.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
James Y Knight via llvm-dev
James Y Knight via llvm-dev
Florian Hahn via llvm-dev
On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:I've also implemented a notification system using GitHub actions that will make
it possible to subscribe to individual issue tags, so we would enable this on Monday
as well.
Roman Lebedev via llvm-dev
> Cheers,
> Florian
Roman
> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
Tom Stellard via llvm-dev
> Hi,
>
>>
>> I've also implemented a notification system using GitHub actions that will make
>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>> as well.
>
> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
>
Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
-Tom
> Cheers,
> Florian
Roman Lebedev via llvm-dev
<cfe...@lists.llvm.org> wrote:
>
> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> > Hi,
> >
> >> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
> >>
> >> I've also implemented a notification system using GitHub actions that will make
> >> it possible to subscribe to individual issue tags, so we would enable this on Monday
> >> as well.
> >
> > Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
> >
>
> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
about every new change
in every issue unless i have explicitly subscribed to the issue?
> -Tom
Roman
> > Cheers,
> > Florian
>
> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
James Henderson via llvm-dev
Florian Hahn via llvm-dev
> On Mar 17, 2020, at 03:06, Tom Stellard <tste...@redhat.com> wrote:
>
> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>> Hi,
>>
>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>>>
>>> I've also implemented a notification system using GitHub actions that will make
>>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>>> as well.
>>
>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
>>
>
> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
I do not have much experience with Github issues, so there might be an easy way to get notifications for new issues only I am not aware of. If that’s possible I guess that would work too. But IMO it would be great if we could keep llvm-bugs alive and working for Github issues as well, to smoothen the transition and to ensure that no issues fall through the cracks. A side benefit of having the emails is that they are easy to view offline & on mobile/search/organize.
Is there any information available for the notification system you mentioned earlier? The default GitHub notifications for llvm-project seem extremely verbose: notification in Github UI for each new issue as well as each interaction on an issue/PR/commit. Assuming 100+ interactions per day on bugzilla, I think it will be very hard to keep up with the notifications.
I think it would help with the transition if we would have a document describing how to migrate common issue interactions, like
* how to get (email) notifications for a single issue (CC on bugzilla)
* how to get (email) notifications for new issues only (current llvm-bugs)
* how to get (email) notifications for a component/label
Tom Stellard via llvm-dev
> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
> <cfe...@lists.llvm.org> wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>>>>
>>>> I've also implemented a notification system using GitHub actions that will make
>>>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>>>> as well.
>>>
>>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
>>>
>>
>> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
> How do i subscribe to only get notified about new issues, but not
> about every new change
> in every issue unless i have explicitly subscribed to the issue?
Is there a way to do this with bugzilla?
-Tom
Roman Lebedev via llvm-dev
>
> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> > On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
> > <cfe...@lists.llvm.org> wrote:
> >>
> >> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> >>> Hi,
> >>>
> >>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
> >>>>
> >>>> I've also implemented a notification system using GitHub actions that will make
> >>>> it possible to subscribe to individual issue tags, so we would enable this on Monday
> >>>> as well.
> >>>
> >>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
> >>>
> >>
> >> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
> > How do i subscribe to only get notified about new issues, but not
> > about every new change
> > in every issue unless i have explicitly subscribed to the issue?
>
> Is there a way to do this with bugzilla?
the bugs of interest.
> -Tom
Roman
Tom Stellard via llvm-dev
>
>
>> On Mar 17, 2020, at 03:06, Tom Stellard <tste...@redhat.com> wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>>>>
>>>> I've also implemented a notification system using GitHub actions that will make
>>>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>>>> as well.
>>>
>>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
>>>
>>
>> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
>
>
> I do not have much experience with Github issues, so there might be an easy way to get notifications for new issues only I am not aware of. If that’s possible I guess that would work too. But IMO it would be great if we could keep llvm-bugs alive and working for Github issues as well, to smoothen the transition and to ensure that no issues fall through the cracks. A side benefit of having the emails is that they are easy to view offline & on mobile/search/organize.
>
> Is there any information available for the notification system you mentioned earlier? The default GitHub notifications for llvm-project seem extremely verbose: notification in Github UI for each new issue as well as each interaction on an issue/PR/commit. Assuming 100+ interactions per day on bugzilla, I think it will be very hard to keep up with the notifications.
>
The notification system I implemented works using GitHub teams and issue
labels. If you want to subscribe to a tag, you join a team and then that
team will get @mentioned when that tag is added to an issue. The mention
will subscribe you to the bug and notify you of future updates.
> I think it would help with the transition if we would have a document describing how to migrate common issue interactions, like
> * how to get (email) notifications for a single issue (CC on bugzilla)
Ok, I will work on this.
> * how to get (email) notifications for new issues only (current llvm-bugs)
Does llvm-bugs really only send notifications for new issues? It doesn't
look that way from the mail archives. e.g. http://lists.llvm.org/pipermail/llvm-bugs/2020-March/082017.html
-Tom
Tom Stellard via llvm-dev
> On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tste...@redhat.com> wrote:
>>
>> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
>>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
>>> <cfe...@lists.llvm.org> wrote:
>>>>
>>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>>>> Hi,
>>>>>
>>>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>>>>>>
>>>>>> I've also implemented a notification system using GitHub actions that will make
>>>>>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>>>>>> as well.
>>>>>
>>>>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
>>>>>
>>>>
>>>> Sending email to llvm-bugs was not planned. Can you use GitHub notifications instead?
>>> How do i subscribe to only get notified about new issues, but not
>>> about every new change
>>> in every issue unless i have explicitly subscribed to the issue?
>>
>> Is there a way to do this with bugzilla?
> That is the current behavior of llvm-bugs@ + manually subscribing to
> the bugs of interest.
>
As I just mentioned in the other mail, looking at the llvm-bugs archive
it looks like there are more than just new bugs e.g.
http://lists.llvm.org/pipermail/llvm-bugs/2020-March/082017.html
-Tom
Robinson, Paul via llvm-dev
> -----Original Message-----
> From: lldb-dev <lldb-dev...@lists.llvm.org> On Behalf Of Tom Stellard
> via lldb-dev
> Sent: Tuesday, March 17, 2020 9:42 AM
> To: Roman Lebedev <lebed...@gmail.com>
> Cc: llvm-dev <llvm...@lists.llvm.org>; cfe-dev <cfe...@lists.llvm.org>;
> Florian Hahn <floria...@apple.com>; LLDB Dev <lldb...@lists.llvm.org>
> Subject: Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla
> to Github Issues
>
> > On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tste...@redhat.com>
> wrote:
> >>
> >> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> >>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
> >>> <cfe...@lists.llvm.org> wrote:
> >>>>
> >>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> >>>>> Hi,
> >>>>>
> >>>>>>
> >>>>>> I've also implemented a notification system using GitHub actions
> that will make
> >>>>>> it possible to subscribe to individual issue tags, so we would
> enable this on Monday
> >>>>>> as well.
> >>>>>
> >>>>> Does this include sending emails for new bugs to llvm-bugs like
> bugzilla does? I am not sure how many people use llvm-bugs, but at least
> for me it is how I keep up with new bug reports.
> >>>>>
> >>>>
> >>>> Sending email to llvm-bugs was not planned. Can you use GitHub
> notifications instead?
> >>> How do i subscribe to only get notified about new issues, but not
> >>> about every new change
> >>> in every issue unless i have explicitly subscribed to the issue?
> >>
> >> Is there a way to do this with bugzilla?
> > That is the current behavior of llvm-bugs@ + manually subscribing to
> > the bugs of interest.
> >
>
> As I just mentioned in the other mail, looking at the llvm-bugs archive
> it looks like there are more than just new bugs e.g.
> http://lists.llvm.org/pipermail/llvm-bugs/2020-March/082017.html
resolved, reopened, like that) but not on every comment.
--paulr
>
> -Tom
>
> >> -Tom
> > Roman
> >
> >>>> -Tom
> >>> Roman
> >>>
> >>>>> Cheers,
> >>>>> Florian
> >>>>
> >>>> _______________________________________________
> >>>> cfe-dev mailing list
> >>>> cfe...@lists.llvm.org
> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>
> >>
> >
>
> _______________________________________________
> lldb...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Richard Smith via llvm-dev
Tom Stellard via llvm-dev
> Please can we shut down one of the two systems for new bugs ASAP? We've already had an instance of someone filing the same bug using both systems, with two different fixes being committed by two different people at the same time...
>
Sure, I just went ahead and updated the repo-lockdown app to auto-close
new issues, and this should go into effect within the next day.
This has been confusing for a lot of people, so I think it's best to
keep GitHub issues disabled until we are ready to switch, which will
hopefully be soon.
-Tom
> On Tue, 17 Mar 2020 at 06:49, Robinson, Paul via cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>> wrote:
>
>
>
> > -----Original Message-----
> > From: lldb-dev <lldb-dev...@lists.llvm.org <mailto:lldb-dev...@lists.llvm.org>> On Behalf Of Tom Stellard
> > via lldb-dev
> > Sent: Tuesday, March 17, 2020 9:42 AM
> > To: Roman Lebedev <lebed...@gmail.com <mailto:lebed...@gmail.com>>
> > Cc: llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>; cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>;
> > Florian Hahn <floria...@apple.com <mailto:floria...@apple.com>>; LLDB Dev <lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org>>
> > Subject: Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla
> > to Github Issues
> >
> > On 03/17/2020 06:39 AM, Roman Lebedev wrote:
> > > On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tste...@redhat.com <mailto:tste...@redhat.com>>
> > wrote:
> > >>
> > >> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> > >>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
> > >>> <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>> wrote:
> > >>>>
> > >>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm-
> > >>>> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
> > >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > >>>
> > >>
> > >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Mehdi AMINI via llvm-dev
On 03/20/2020 12:31 PM, Richard Smith wrote:
> Please can we shut down one of the two systems for new bugs ASAP? We've already had an instance of someone filing the same bug using both systems, with two different fixes being committed by two different people at the same time...
>
Sure, I just went ahead and updated the repo-lockdown app to auto-close
new issues, and this should go into effect within the next day.
Tom Stellard via llvm-dev
>
>
> On Fri, Mar 20, 2020 at 12:47 PM Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>
> On 03/20/2020 12:31 PM, Richard Smith wrote:
> > Please can we shut down one of the two systems for new bugs ASAP? We've already had an instance of someone filing the same bug using both systems, with two different fixes being committed by two different people at the same time...
> >
>
> Sure, I just went ahead and updated the repo-lockdown app to auto-close
> new issues, and this should go into effect within the next day.
>
>
> Contrary to pull-requests, issues can be just disabled from the config. Can we do this instead?
>
Yes, thanks for reminding me about that.
-Tom
> Thanks,
>
> --
> Mehdi
>
>
> This has been confusing for a lot of people, so I think it's best to
> keep GitHub issues disabled until we are ready to switch, which will
> hopefully be soon.
>
> -Tom
>
> > On Tue, 17 Mar 2020 at 06:49, Robinson, Paul via cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: lldb-dev <lldb-dev...@lists.llvm.org <mailto:lldb-dev...@lists.llvm.org> <mailto:lldb-dev...@lists.llvm.org <mailto:lldb-dev...@lists.llvm.org>>> On Behalf Of Tom Stellard
> > > via lldb-dev
> > > Sent: Tuesday, March 17, 2020 9:42 AM
> > > To: Roman Lebedev <lebed...@gmail.com <mailto:lebed...@gmail.com> <mailto:lebed...@gmail.com <mailto:lebed...@gmail.com>>>
> > > Cc: llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>>; cfe-dev <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>>;
> > > Florian Hahn <floria...@apple.com <mailto:floria...@apple.com> <mailto:floria...@apple.com <mailto:floria...@apple.com>>>; LLDB Dev <lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org> <mailto:lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org>>>
> > > Subject: Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla
> > > to Github Issues
> > >
> > > On 03/17/2020 06:39 AM, Roman Lebedev wrote:
> > > > On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tste...@redhat.com <mailto:tste...@redhat.com> <mailto:tste...@redhat.com <mailto:tste...@redhat.com>>>
> > > wrote:
> > > >>
> > > >> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> > > >>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
> > > >>> <cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>> wrote:
> > > >>>>
> > > >>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm-
> > > >>>> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>
> > > >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > > >>>
> > > >>
> > > >
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org> <mailto:lldb...@lists.llvm.org <mailto:lldb...@lists.llvm.org>>
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > _______________________________________________
> > cfe-dev mailing list
> > cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org> <mailto:cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Tom Stellard via llvm-dev
> On Mon, Mar 16, 2020 at 8:13 PM Florian Hahn via cfe-dev
> <cfe...@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> I've also implemented a notification system using GitHub actions that will make
>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>> as well.
>>
>>
>> Does this include sending emails for new bugs to llvm-bugs like bugzilla does? I am not sure how many people use llvm-bugs, but at least for me it is how I keep up with new bug reports.
> +1
>
I have been looking into this over the last week and was able to get something
working that will email llvm-bugs when an issue is opened, closed, or reopened.
Here is an example email, let me know if there is anything else I should add:
<headers>
FROM: llvml...@llvm.org
Reply-To: llvm...@lists.llvm.org
Subject: [Issue 11] Another emailer test
</headers>
<body>
https://github.com/llvm/temp-issue-tester/issues/11
Title: Another emailer test
Reporter: tstellar
State: open
Test description.
</body>
-Tom
Tom Stellard via llvm-dev
> On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
> <cfe...@lists.llvm.org> wrote:
>>
>> On 02/10/2020 07:40 PM, Tom Stellard wrote:
>>> On 01/30/2020 12:47 PM, David Major wrote:
>>>> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>>>>
>>>
>>> Yes, I think this makes sense, let's postpone until then.
>>>
>>
>> Hi,
>>
>> 10.0.0-rc4 was just released, and I think we are at the point in the release cycle
>> where it is safe to begin the migration to GitHub issues.
>>
>> I would like to propose doing the migration in one week (March 23). This means
>> making the existing bugzilla read-only, and updating the documentation to tell users
>> from bugzilla into GitHub, so this step will be done at a later date.
>>
>> used categories in bugzilla. This should be enough to get us started and we can always
>> add more tags as we go.
>>
>> it possible to subscribe to individual issue tags, so we would enable this on Monday
>> as well.
>>
>
> I am uncomfortable switching to GitHub issues unless the initial
> result is that we have ONE set of bugs to track (I do not want to have
> to search and maintain separate bug lists). Moving bugs from Bugzilla
> at an unspecified future time is a deal-breaker for me, so -1.
Is there anything we could do to make having active issues in both
trackers easier to deal with?
-Tom
>
> ~Aaron
>
>>
>> Thanks,
>> Tom
>>
>>
>>> -Tom
>>>
>>>>
>>>>
>>>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>>>>
>>>> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>>>> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>>>> >>> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
>>>> >>>
>>>> >>> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>>>> >>>
>>>> >>> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>>>> >>>
>>>> >>>
>>>> >>> Proposal
>>>> >>> ----
>>>> >>> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>>>> >>>
>>>> >>> Some things we'd like to get in place before turning on Github's Issue tracker:
>>>> >>> 1. Updated documentation.
>>>> >>> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
>>>> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>>>> >>>
>>>> >>> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>>>> >>>
>>>> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>>>> >>>
>>>> >>> 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...@llvm.org <mailto:llvm...@llvm.org> <mailto:llvm...@llvm.org <mailto:llvm...@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).
>>>> >>>
>>>> >>> Further steps
>>>> >>> ----
>>>> >>> After we migrate, there's still things we want to do:
>>>> >>>
>>>> >>> 1. Discuss and setup new and better procedures around bug triage and prioritization.
>>>> >>>
>>>> >>> What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
>>>> >>>
>>>> >>> 2. Bug migration
>>>> >>>
>>>> >>> /After/ the initial switchover, we do want to investigate two possibilities for migrating issues and turning off the bugzilla server. I expect which one is chosen will come down mostly to feasibility of implementation.
>>>> >>>
>>>> >>> 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.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> LLVM Developers mailing list
>>>> >>> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
>>>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> >>>
>>>> >>
>>>> >> _______________________________________________
>>>> >> cfe-dev mailing list
>>>> >> cfe...@lists.llvm.org <mailto:cfe...@lists.llvm.org>
>>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>> >
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev