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

Fangrui Song via cfe-dev
On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads.
>
> Most of the ideas here were from other people. I /believe/ this proposal represents the overall feeling of the folks at the round-table, in spirit if not in exact details, but nobody else has reviewed this text, so I can't make any specific such claim as to who the "we" represents, other than myself. Just assume all the good ideas here were from others, and all the bad parts I misremembered or invented.
>
>

Hi,

I want to restart this discussion.  There seemed to be support for this,
but we got held up trying to decide on the appropriate set of tags to
use to classify issues.

I propose that we move forward with this proposal and disable creation of
new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
issues from that date forward.

I think that for choosing the tags to use, we should just take requests
from the community over the next week and add whatever is asked for.  The main
purpose of adding tags is so we can setup cc lists for bugs, so I think this
is a good way to ensure that we have tags people care about.  We can always
add more tags later if necessary.

What does everyone think about this?

-Tom


> Background
> ----
> Our bugzilla installation is...not great. It's been not-great for a long time now.
>
> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
>
> This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>
> GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>
>
> Proposal
> ----
> We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>
> Some things we'd like to get in place before turning on Github's Issue tracker:
> 1. Updated documentation.
> 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>
> But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>
> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>
> We do /not/ want to build supplementary notification systems to make github issues send additional emails that it is unable to send itself. We will only support what GitHub supports. That means:
> - You can subscribe to notification emails for activity in the entire llvm-project repository.
> - You can subscribe to notification emails on an individual issue.
> - Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).
> - No emails will be sent to [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]
> 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

Fangrui Song via cfe-dev
On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
<[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?

~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>'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]> 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]
> > 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

Fangrui Song via cfe-dev
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]> 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>'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]> 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]
>>> 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

Fangrui Song via cfe-dev
My concern about switching is that I will now need to use two issue trackers instead of one when doing things like searching for related bugs.

~Aaron

On Thu, Jan 30, 2020, 1:31 PM Tom Stellard <[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]> 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>'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]> 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]
>>> 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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Hi,




On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev <[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.

Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
Mailing-lists seem fairly rigid in terms of granularity with respect to tags.

-- 
Mehdi



 

What does everyone think about this?

-Tom


> Background
> ----
> Our bugzilla installation is...not great. It's been not-great for a long time now.
>
> Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org>'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]> 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]
> 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

Fangrui Song via cfe-dev
On 01/30/2020 10:48 AM, Mehdi AMINI wrote:

> Hi,
>
>
>
>
> On Thu, Jan 30, 2020 at 10:21 AM 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.
>
>
> Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>

When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.

From what I can tell, there are a couple different ways to auto-subscribe
people using github actions.  I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.

I was planning to experiment more with this over the next few days.

-Tom





> --
> Mehdi
>
>
>
>  
>
>
>     What does everyone think about this?
>
>     -Tom
>
>
>     > Background
>     > ----
>     > Our bugzilla installation is...not great. It's been not-great for a long time now.
>     >
>     > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
>     >
>     > This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>     >
>     > GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>     >
>     >
>     > Proposal
>     > ----
>     > We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>     >
>     > Some things we'd like to get in place before turning on Github's Issue tracker:
>     > 1. Updated documentation.
>     > 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
>     > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>     >
>     > But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>     >
>     > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>     >
>     > We do /not/ want to build supplementary notification systems to make github issues send additional emails that it is unable to send itself. We will only support what GitHub supports. That means:
>     > - You can subscribe to notification emails for activity in the entire llvm-project repository.
>     > - You can subscribe to notification emails on an individual issue.
>     > - Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).
>     > - No emails will be sent to [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
>

_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
On Thu, 30 Jan 2020 13:24:10 -0500, Aaron Ballman via cfe-dev said:

>> What does everyone think about this?
>
>What did we decide to do with all the existing issues in Bugzilla?

Will you be able to start numbering in github at a number larger than the largest bug in bugzilla?  It would be annoying to have overlapping bug numbers.  Bug numbers exist in code comments, list archives, etc., etc.  If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.

Sean


_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <[hidden email]> wrote:
Hi,

I want to restart this discussion.  There seemed to be support for this,
but we got held up trying to decide on the appropriate set of tags to
use to classify issues.

I propose that we move forward with this proposal and disable creation of
new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
issues from that date forward.

I think that for choosing the tags to use, we should just take requests
from the community over the next week and add whatever is asked for.  The main
purpose of adding tags is so we can setup cc lists for bugs, so I think this
is a good way to ensure that we have tags people care about.  We can always
add more tags later if necessary.

What does everyone think about this?

Before disabling Bugzilla, I think there should be a way for those who don't have/want github accounts to create/comment-on bug reports (maybe a mailing list with a thread per bug?). Once that's done, I'm all for switching to github.

Jacob

_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?



On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <[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]> 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>'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]> 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]
>>> 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
>

_______________________________________________
LLVM Developers mailing list
[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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
> Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
No, all notifications are essentially all-or-nothing thing. Github
folks knows about this issue and planned to work on them, but there
was no ETA on this.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
  

_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
> Will you be able to start numbering in github at a number larger than the largest bug in bugzilla? It would be annoying to have overlapping bug numbers. Bug numbers exist in code comments, list archives, etc., etc. If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.
This won't work in general, unfortunately as there are already a bunch
of PRs and issues opened... And github uses consecutive numbering for
all PRs, issues and such... So, there is already overlap here.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
  

_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
I tend to support this – after 10.0.0 seems like a proper timeline.
And we already have some set of tags from bugzilla, so we could simply add them.
On Thu, Jan 30, 2020 at 8:49 PM David Major via llvm-dev
wrote:
>
> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?
>
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev wrote:
>>
>> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> > 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 '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] 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]
>> >>> 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
>> >
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
  

_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.

On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <[hidden email]> wrote:
On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> Hi,
>
>
>
>
> On Thu, Jan 30, 2020 at 10:21 AM 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.
>
>
> Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>

When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.

From what I can tell, there are a couple different ways to auto-subscribe
people using github actions.  I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.

I was planning to experiment more with this over the next few days.

-Tom





> --
> Mehdi
>
>
>

>
>
>     What does everyone think about this?
>
>     -Tom
>
>
>     > Background
>     > ----
>     > Our bugzilla installation is...not great. It's been not-great for a long time now.
>     >
>     > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which is much nicer. I thought we would be able to upgrade to that. But there has been no such release, and not much apparent progress towards such. I can't say with any confidence that there will ever be. I no longer believe it really makes sense to continue using bugzilla.
>     >
>     > This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating /whether/ we should switch, we discussed /how/ we should switch. And came up with a plan to switch quickly.
>     >
>     > GitHub issues may not be perfect, but I see other similarly-large projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it should be good for us, as well. Importantly, Github Issues is significantly less user-hostile than our bugzilla is, for new contributors and downstream developers who just want to tell us about bugs!
>     >
>     >
>     > Proposal
>     > ----
>     > We propose to enable Github issues for the llvm-project repository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla.
>     >
>     > Some things we'd like to get in place before turning on Github's Issue tracker:
>     > 1. Updated documentation.
>     > 2. An initial set of issue tags we'd like to use for triaging/categorizing issues.
>     > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.
>     >
>     > But more important are the things we do /not/ want to make prerequisites for turning on Github issues:
>     >
>     > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the existing issues to GitHub as a prerequisite for switching. We will thus expect that people continue using bugzilla for commenting on the existing bugs -- for the moment.
>     >
>     > We do /not/ want to build supplementary notification systems to make github issues send additional emails that it is unable to send itself. We will only support what GitHub supports. That means:
>     > - You can subscribe to notification emails for activity in the entire llvm-project repository.
>     > - You can subscribe to notification emails on an individual issue.
>     > - Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).
>     > - No emails will be sent to [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]
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

Fangrui Song via cfe-dev
On 01/31/2020 01:21 AM, James Henderson wrote:
> My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.
>

Would you be able to help me test some potential solutions for this?

-Tom

> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
>     > Hi,
>     >
>     >
>     >
>     >
>     > On Thu, Jan 30, 2020 at 10:21 AM 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.
>     >
>     >
>     > Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
>     > Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>     >
>
>     When I said cc lists, I really meant auto-subscribe lists, I didn't mean
>     that we would start sending issue emails to mailing lists.
>
>     From what I can tell, there are a couple different ways to auto-subscribe
>     people using github actions.  I think the most simple would be to use
>     the assignee field, but I think it's also possible by @ mentioning people
>     directly in a comment or @ mentioning teams.
>
>     I was planning to experiment more with this over the next few days.
>
>     -Tom
>
>
>
>
>
>     > --
>     > Mehdi
>     >
>     >
>     >
>     >
>     >
>     >
>     >     What does everyone think about this?
>     >
>     >     -Tom
>     >
>     >
>     >     > Background
>     >     > ----
>     >     > Our bugzilla installation is...not great. It's been not-great for a long time now.
>     >     >
>     >     > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org> <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]>
>     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

Fangrui Song via cfe-dev
On 2020-01-31, Tom Stellard via llvm-dev wrote:
>On 01/31/2020 01:21 AM, James Henderson wrote:
>> My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.
>>
>
>Would you be able to help me test some potential solutions for this?

My feeling is similar to James'.

+1 if auto subscription is available (similar to Herald rules).
-1 if it isn't.

And I guess contributors may need to change the notification setting from "Watching" to "Not watching",
to avoid issue spam.


Tom, I'd like to be a tester.

>
>> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
>>     > Hi,
>>     >
>>     >
>>     >
>>     >
>>     > On Thu, Jan 30, 2020 at 10:21 AM 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.
>>     >
>>     >
>>     > Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
>>     > Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>>     >
>>
>>     When I said cc lists, I really meant auto-subscribe lists, I didn't mean
>>     that we would start sending issue emails to mailing lists.
>>
>>     From what I can tell, there are a couple different ways to auto-subscribe
>>     people using github actions.  I think the most simple would be to use
>>     the assignee field, but I think it's also possible by @ mentioning people
>>     directly in a comment or @ mentioning teams.
>>
>>     I was planning to experiment more with this over the next few days.
>>
>>     -Tom
>>
>>
>>
>>
>>
>>     > --
>>     > Mehdi
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >     What does everyone think about this?
>>     >
>>     >     -Tom
>>     >
>>     >
>>     >     > Background
>>     >     > ----
>>     >     > Our bugzilla installation is...not great. It's been not-great for a long time now.
>>     >     >
>>     >     > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org> <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]>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>_______________________________________________
>LLVM Developers mailing list
>[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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
On 2020-01-30, Anton Korobeynikov via cfe-dev wrote:
>> Will you be able to start numbering in github at a number larger than the largest bug in bugzilla?  It would be annoying to have overlapping bug numbers.  Bug numbers exist in code comments, list archives, etc., etc.  If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.
>This won't work in general, unfortunately as there are already a bunch
>of PRs and issues opened... And github uses consecutive numbering for
>all PRs, issues and such... So, there is already overlap here.

It'd be nice if Github allows to bump the issue counter to 44000+ .
(current largest https://bugs.llvm.org/show_bug.cgi?id= id is 44000+)

Then the website can set up a redirector:

http://llvm.org/PR1 => https://bugs.llvm.org/show_bug.cgi?id=1
...
http://llvm.org/PR44000 => https://bugs.llvm.org/show_bug.cgi?id=44000
...
http://llvm.org/PR45000 => https://github.com/llvm/llvm-project/issue/45000
http://llvm.org/PR50000 => https://github.com/llvm/llvm-project/issue/50000
_______________________________________________
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

Fangrui Song via cfe-dev
Good idea. Let me ask for this.

On Sat, Feb 1, 2020 at 2:17 AM Fangrui Song via llvm-dev
<[hidden email]> wrote:

>
> On 2020-01-30, Anton Korobeynikov via cfe-dev wrote:
> >> Will you be able to start numbering in github at a number larger than the largest bug in bugzilla?  It would be annoying to have overlapping bug numbers.  Bug numbers exist in code comments, list archives, etc., etc.  If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame.
> >This won't work in general, unfortunately as there are already a bunch
> >of PRs and issues opened... And github uses consecutive numbering for
> >all PRs, issues and such... So, there is already overlap here.
>
> It'd be nice if Github allows to bump the issue counter to 44000+ .
> (current largest https://bugs.llvm.org/show_bug.cgi?id= id is 44000+)
>
> Then the website can set up a redirector:
>
> http://llvm.org/PR1 => https://bugs.llvm.org/show_bug.cgi?id=1
> ...
> http://llvm.org/PR44000 => https://bugs.llvm.org/show_bug.cgi?id=44000
> ...
> http://llvm.org/PR45000 => https://github.com/llvm/llvm-project/issue/45000
> http://llvm.org/PR50000 => https://github.com/llvm/llvm-project/issue/50000
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
_______________________________________________
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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
I'm happy to test things out, as long as it's not too much of a time sink (I have a lot on my plate at the moment, so something that takes more than the odd few minutes here and there may not be feasible).

On Sat, 1 Feb 2020 at 02:10, Fangrui Song <[hidden email]> wrote:
On 2020-01-31, Tom Stellard via llvm-dev wrote:
>On 01/31/2020 01:21 AM, James Henderson wrote:
>> My only concern is the ability to get auto-subscribed onto issues for specific tools (i.e. the setup I currently have). If that can be resolved in a satisfactory manner, then I'm all for this (although less than two weeks seems like a rather ambitious time to switch over...). If it can't, then I'd be opposed to switching at all.
>>
>
>Would you be able to help me test some potential solutions for this?

My feeling is similar to James'.

+1 if auto subscription is available (similar to Herald rules).
-1 if it isn't.

And I guess contributors may need to change the notification setting from "Watching" to "Not watching",
to avoid issue spam.


Tom, I'd like to be a tester.

>
>> On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
>>     > Hi,
>>     >
>>     >
>>     >
>>     >
>>     > On Thu, Jan 30, 2020 at 10:21 AM 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.
>>     >
>>     >
>>     > Do we have a way for individuals to get individually automatically subscribed on all the bugs created for a given tag?
>>     > Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>>     >
>>
>>     When I said cc lists, I really meant auto-subscribe lists, I didn't mean
>>     that we would start sending issue emails to mailing lists.
>>
>>     From what I can tell, there are a couple different ways to auto-subscribe
>>     people using github actions.  I think the most simple would be to use
>>     the assignee field, but I think it's also possible by @ mentioning people
>>     directly in a comment or @ mentioning teams.
>>
>>     I was planning to experiment more with this over the next few days.
>>
>>     -Tom
>>
>>
>>
>>
>>
>>     > --
>>     > Mehdi
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >     What does everyone think about this?
>>     >
>>     >     -Tom
>>     >
>>     >
>>     >     > Background
>>     >     > ----
>>     >     > Our bugzilla installation is...not great. It's been not-great for a long time now.
>>     >     >
>>     >     > Last year, I argued against switching to github issues. I was somewhat optimistic that it was possible to improve our bugzilla in some incremental ways...but we haven't. Additionally, the upstream bugzilla project was supposed to make a new release of bugzilla ("harmony"), based on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org> <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]>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>_______________________________________________
>LLVM Developers mailing list
>[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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song via cfe-dev
Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev
<[hidden email]>:

>
> On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <[hidden email]> wrote:
>>
>> Hi,
>>
>> I want to restart this discussion.  There seemed to be support for this,
>> but we got held up trying to decide on the appropriate set of tags to
>> use to classify issues.
>>
>> I propose that we move forward with this proposal and disable creation of
>> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
>> issues from that date forward.
>>
>> I think that for choosing the tags to use, we should just take requests
>> from the community over the next week and add whatever is asked for.  The main
>> purpose of adding tags is so we can setup cc lists for bugs, so I think this
>> is a good way to ensure that we have tags people care about.  We can always
>> add more tags later if necessary.
>>
>> What does everyone think about this?
>
>
> Before disabling Bugzilla, I think there should be a way for those who don't have/want github accounts to create/comment-on bug reports (maybe a mailing list with a thread per bug?). Once that's done, I'm all for switching to github.

This adds a burden on everyone to observe two locations for bugs. By
comparison creating a GitHub account is simple. Even creating a
bugzilla account is more difficult.

Michael
_______________________________________________
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

Fangrui Song via cfe-dev
On Mon, Feb 3, 2020, 09:00 Michael Kruse <[hidden email]> wrote:
Am Do., 30. Jan. 2020 um 13:29 Uhr schrieb Jacob Lifshay via cfe-dev
<[hidden email]>:
>
> On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev <[hidden email]> wrote:
>>
>> Hi,
>>
>> I want to restart this discussion.  There seemed to be support for this,
>> but we got held up trying to decide on the appropriate set of tags to
>> use to classify issues.
>>
>> I propose that we move forward with this proposal and disable creation of
>> new bugs in bugzilla on Feb 11, and require all new bugs be filed via GitHub
>> issues from that date forward.
>>
>> I think that for choosing the tags to use, we should just take requests
>> from the community over the next week and add whatever is asked for.  The main
>> purpose of adding tags is so we can setup cc lists for bugs, so I think this
>> is a good way to ensure that we have tags people care about.  We can always
>> add more tags later if necessary.
>>
>> What does everyone think about this?
>
>
> Before disabling Bugzilla, I think there should be a way for those who don't have/want github accounts to create/comment-on bug reports (maybe a mailing list with a thread per bug?). Once that's done, I'm all for switching to github.

This adds a burden on everyone to observe two locations for bugs. By
comparison creating a GitHub account is simple. Even creating a
bugzilla account is more difficult.

I think it should be relatively easy to automate using github's APIs.

The issue is not the ease of signing up for github, but that there are some people who specifically don't have or want GitHub accounts because they don't want to use proprietary software or were prevented by GitHub's rules (Iran or similar places, don't know that we would legally be able to post on GitHub on their behalf though).

I personally don't have either issue, but do know some people with the former issue who are using LLVM as part of their job.

Jacob

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