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

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-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.

-Tom

>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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
>     > <[hidden email] <mailto:[hidden email]>> 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
>     >
>     >>
>     >> -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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> 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
>     >>> [hidden email] <mailto:[hidden email]>
>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>>
>     >>
>     >> _______________________________________________
>     >> cfe-dev mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     >
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-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.

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


> -Tom
>
>>
>>
>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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
>>     > <[hidden email] <mailto:[hidden email]>> 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
>>     >
>>     >>
>>     >> -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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> 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
>>     >>> [hidden email] <mailto:[hidden email]>
>>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>     >>>
>>     >>
>>     >> _______________________________________________
>>     >> cfe-dev mailing list
>>     >> [hidden email] <mailto:[hidden email]>
>>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>     >
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
<[hidden email]> 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

>
> Thanks,
> Tom
>
>
> > -Tom
> >
> >>
> >>
> >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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
> >>     > <[hidden email] <mailto:[hidden email]>> 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
> >>     >
> >>     >>
> >>     >> -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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> 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
> >>     >>> [hidden email] <mailto:[hidden email]>
> >>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>     >>>
> >>     >>
> >>     >> _______________________________________________
> >>     >> cfe-dev mailing list
> >>     >> [hidden email] <mailto:[hidden email]>
> >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>     >
> >>
> >>     _______________________________________________
> >>     LLVM Developers mailing list
> >>     [hidden email] <mailto:[hidden email]>
> >>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Mon, Mar 16, 2020 at 10:53 AM Aaron Ballman via cfe-dev <[hidden email]> wrote:
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.
Further to Aaron's point, do we have a recommended conventions (e.g., llvm/llvm-project#1 or something less verbose) for referring to issues on GitHub (from code, from commit messages, from other bug reports, etc.) in a manner that is unambiguous with the convention used to refer to Bugzilla bugs? Have we documented said conventions in the appropriate places? In particular, we should discourage use of conventions where Bugzilla bugs result in links to non-corresponding GitHub issues.
 

~Aaron

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev


On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <[hidden email]> 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?
 

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.
 

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


> -Tom
>
>>
>>
>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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
>>     > <[hidden email] <mailto:[hidden email]>> 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
>>     >
>>     >>
>>     >> -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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> 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
>>     >>> [hidden email] <mailto:[hidden email]>
>>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>     >>>
>>     >>
>>     >> _______________________________________________
>>     >> cfe-dev mailing list
>>     >> [hidden email] <mailto:[hidden email]>
>>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>     >
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On 03/16/2020 08:00 AM, James Henderson wrote:

>
>
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <[hidden email] <mailto:[hidden email]>> 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

>
>
>     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
>
>
>     > -Tom
>     >
>     >>
>     >>
>     >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     > <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >
>     >>     >>
>     >>     >> -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> <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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>     >>>
>     >>     >>
>     >>     >> _______________________________________________
>     >>     >> cfe-dev mailing list
>     >>     >> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     >>     >
>     >>
>     >>     _______________________________________________
>     >>     LLVM Developers mailing list
>     >>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>
>     >
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev


On Mon, 16 Mar 2020 at 15:08, Tom Stellard <[hidden email]> wrote:
On 03/16/2020 08:00 AM, James Henderson wrote:
>
>
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <[hidden email] <mailto:[hidden email]>> 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

That's what I thought might be the case, and where I take issue with it. I've said this on several previous occasions - I think it makes sense for tags/bugzilla components etc. to exist for each individual executable, as well as the various libraries. Let's say I'm a user of a tool like llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't know where to file it (and no, I don't think a catch-all "binutils" tag is useful - not every developer will know what counts as a "binutils" tag). At the time of writing there are exactly three bugs for llvm-size. That presumably isn't going to meet any threshold imposed, so this tag wouldn't be created, and I wouldn't know where to file my bug, so I probably would either guess (and quite likely get it wrong), or not add a tag, which means that developers who are focused on developing the binutils (and would therefore have subscribed to this tag) won't see the issue. I might even not file the bug at all.


>
>
>     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
>
>
>     > -Tom
>     >
>     >>
>     >>
>     >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     > <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >
>     >>     >>
>     >>     >> -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> <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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>     >>>
>     >>     >>
>     >>     >> _______________________________________________
>     >>     >> cfe-dev mailing list
>     >>     >> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     >>     >
>     >>
>     >>     _______________________________________________
>     >>     LLVM Developers mailing list
>     >>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>
>     >
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
I think we ought to setup some sort of organized scheme for volunteers to do triage of incoming issues, to make sure they've got enough actionable info, and direct to the correct people as needed.

(This would actually be a really nice thing to have, regardless of which bugtracking system we have.)

On Mon, Mar 16, 2020 at 11:41 AM James Henderson via cfe-dev <[hidden email]> wrote:


On Mon, 16 Mar 2020 at 15:08, Tom Stellard <[hidden email]> wrote:
On 03/16/2020 08:00 AM, James Henderson wrote:
>
>
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <[hidden email] <mailto:[hidden email]>> 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

That's what I thought might be the case, and where I take issue with it. I've said this on several previous occasions - I think it makes sense for tags/bugzilla components etc. to exist for each individual executable, as well as the various libraries. Let's say I'm a user of a tool like llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't know where to file it (and no, I don't think a catch-all "binutils" tag is useful - not every developer will know what counts as a "binutils" tag). At the time of writing there are exactly three bugs for llvm-size. That presumably isn't going to meet any threshold imposed, so this tag wouldn't be created, and I wouldn't know where to file my bug, so I probably would either guess (and quite likely get it wrong), or not add a tag, which means that developers who are focused on developing the binutils (and would therefore have subscribed to this tag) won't see the issue. I might even not file the bug at all.


>
>
>     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
>
>
>     > -Tom
>     >
>     >>
>     >>
>     >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     > <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >
>     >>     >>
>     >>     >> -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> <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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>     >>>
>     >>     >>
>     >>     >> _______________________________________________
>     >>     >> cfe-dev mailing list
>     >>     >> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     >>     >
>     >>
>     >>     _______________________________________________
>     >>     LLVM Developers mailing list
>     >>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>
>     >
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
Hi,

On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email]> 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.

Cheers,
Florian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Mon, Mar 16, 2020 at 8:13 PM Florian Hahn via cfe-dev
<[hidden email]> wrote:

>
> Hi,
>
> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email]> 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


> Cheers,
> Florian
Roman

> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
On 03/16/2020 10:13 AM, Florian Hahn wrote:

> Hi,
>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?

-Tom

> Cheers,
> Florian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
<[hidden email]> wrote:

>
> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> > Hi,
> >
> >> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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?

> -Tom
Roman

> > Cheers,
> > Florian
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
Quite possibly. I am one of the current self-volunteered triagers on each of the GNU-equivalent LLVM binutils, and somebody who is therefore on the CC list for several bugzilla components with small numbers. I don't have the expertise to triage 95% of issues that come in elsewhere so me being in some kind of high-level bug triager group would simply not work (I don't have the time or desire to sift through other bugs). Similarly, do we expect the people in this proposed triager group to have sufficient knowledge about all parts of LLVM to redirect things appropriately? And how would they redirect things? They could assign an llvm-readelf issue to me or one of the other active maintainers in the corresponding area, for example, but that doesn't mean I'm going to do anything about it (I'll triage incoming bugs, but not necessarily fix most of them - I get paid to work with LLVM, so if there's no business need from my company's point of view, it's unlikely I'll ever look at it beyond the initial triage). That would therefore imply we need a component for the issue to be assigned to so that interested parties can fix it, people who are trying to find out whether something is a known issue can find it, etc.

I agree that each component should have its own group of triagers so that things don't fall into an unacknowledged black hole, but I think these need to be focused components on small areas. A clear breakdown to me is a component for each "project" where I define a project to be something that appears in Visual Studio as such, which in turn translates into each library and each executable (with some obvious exceptions where the library is used by only a single executable or similar such situation).

What is wrong with component tags that aren't necessarily used all that often?

On Mon, 16 Mar 2020 at 16:24, James Y Knight <[hidden email]> wrote:
I think we ought to setup some sort of organized scheme for volunteers to do triage of incoming issues, to make sure they've got enough actionable info, and direct to the correct people as needed.

(This would actually be a really nice thing to have, regardless of which bugtracking system we have.)

On Mon, Mar 16, 2020 at 11:41 AM James Henderson via cfe-dev <[hidden email]> wrote:


On Mon, 16 Mar 2020 at 15:08, Tom Stellard <[hidden email]> wrote:
On 03/16/2020 08:00 AM, James Henderson wrote:
>
>
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <[hidden email] <mailto:[hidden email]>> 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

That's what I thought might be the case, and where I take issue with it. I've said this on several previous occasions - I think it makes sense for tags/bugzilla components etc. to exist for each individual executable, as well as the various libraries. Let's say I'm a user of a tool like llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't know where to file it (and no, I don't think a catch-all "binutils" tag is useful - not every developer will know what counts as a "binutils" tag). At the time of writing there are exactly three bugs for llvm-size. That presumably isn't going to meet any threshold imposed, so this tag wouldn't be created, and I wouldn't know where to file my bug, so I probably would either guess (and quite likely get it wrong), or not add a tag, which means that developers who are focused on developing the binutils (and would therefore have subscribed to this tag) won't see the issue. I might even not file the bug at all.


>
>
>     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
>
>
>     > -Tom
>     >
>     >>
>     >>
>     >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     > <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >
>     >>     >>
>     >>     >> -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> <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 [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >>     >>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>     >>>
>     >>     >>
>     >>     >> _______________________________________________
>     >>     >> cfe-dev mailing list
>     >>     >> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     >>     >
>     >>
>     >>     _______________________________________________
>     >>     LLVM Developers mailing list
>     >>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     >>
>     >
>
>     _______________________________________________
>     cfe-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev


> On Mar 17, 2020, at 03:06, Tom Stellard <[hidden email]> wrote:
>
> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>> Hi,
>>
>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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

Cheers,
Florian



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-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
> <[hidden email]> wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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

>
>> -Tom
> Roman
>
>>> Cheers,
>>> Florian
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <[hidden email]> 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
> > <[hidden email]> wrote:
> >>
> >> On 03/16/2020 10:13 AM, Florian Hahn wrote:
> >>> Hi,
> >>>
> >>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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.

> -Tom
Roman

> >> -Tom
> > Roman
> >
> >>> Cheers,
> >>> Florian
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> [hidden email]
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
On 03/17/2020 03:11 AM, Florian Hahn wrote:

>
>
>> On Mar 17, 2020, at 03:06, Tom Stellard <[hidden email]> wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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

> * how to get (email) notifications for a component/label
>
> Cheers,
> Florian
>
>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
On 03/17/2020 06:39 AM, Roman Lebedev wrote:

> On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>>
>>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>>>> Hi,
>>>>>
>>>>>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> 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

>> -Tom
> Roman
>
>>>> -Tom
>>> Roman
>>>
>>>>> Cheers,
>>>>> Florian
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev


> -----Original Message-----
> From: lldb-dev <[hidden email]> On Behalf Of Tom Stellard
> via lldb-dev
> Sent: Tuesday, March 17, 2020 9:42 AM
> To: Roman Lebedev <[hidden email]>
> Cc: llvm-dev <[hidden email]>; cfe-dev <[hidden email]>;
> Florian Hahn <[hidden email]>; LLDB Dev <[hidden email]>
> 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 <[hidden email]>
> 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
> >>> <[hidden email]> 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-
> [hidden email] <mailto:[hidden email]>> 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

llvm-bugs is set to receive notifications on a status change (new bug,
resolved, reopened, like that) but not on every comment.
--paulr

>
> -Tom
>
> >> -Tom
> > Roman
> >
> >>>> -Tom
> >>> Roman
> >>>
> >>>>> Cheers,
> >>>>> Florian
> >>>>
> >>>> _______________________________________________
> >>>> cfe-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>
> >>
> >
>
> _______________________________________________
> lldb-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-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...

On Tue, 17 Mar 2020 at 06:49, Robinson, Paul via cfe-dev <[hidden email]> wrote:


> -----Original Message-----
> From: lldb-dev <[hidden email]> On Behalf Of Tom Stellard
> via lldb-dev
> Sent: Tuesday, March 17, 2020 9:42 AM
> To: Roman Lebedev <[hidden email]>
> Cc: llvm-dev <[hidden email]>; cfe-dev <[hidden email]>;
> Florian Hahn <[hidden email]>; LLDB Dev <[hidden email]>
> 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 <[hidden email]>
> 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
> >>> <[hidden email]> 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-
> [hidden email] <mailto:[hidden email]>> 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

llvm-bugs is set to receive notifications on a status change (new bug,
resolved, reopened, like that) but not on every comment.
--paulr

>
> -Tom
>
> >> -Tom
> > Roman
> >
> >>>> -Tom
> >>> Roman
> >>>
> >>>>> Cheers,
> >>>>> Florian
> >>>>
> >>>> _______________________________________________
> >>>> cfe-dev mailing list
> >>>> [hidden email]
> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>
> >>
> >
>
> _______________________________________________
> lldb-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
123