I think if we start here we can create more specialized tags as
GitHub issues gets more traffic and we have more experience using it.
The google doc I created contains the slightly cleaned list of current
components. It could be used as a good starting point for defining a
list of tags.
+1 to using Anton’s list as a starting point. I think the top-level directories llvm-project + backends are not really fine-grained enough for some areas. For example, the code related to the various LLVM binary utilities like llvm-readobj/llvm-objcopy/llvm-symbolizer etc is all contained within llvm/tools, and wouldn’t have their own tag, or even one closely related (“llvm” would be the tag they’d come under, which is… less than useful). Separate tags for each tool (possibly with some shared ones for tools which are broadly aliases like llvm-objcopy/llvm-strip and llvm-readelf/llvm-readobj etc) would certainly help me. Bugzilla already has most of these.
+1 to using Anton's list as a starting point. I think the top-level directories llvm-project + backends are not really fine-grained enough for some areas. For example, the code related to the various LLVM binary utilities like llvm-readobj/llvm-objcopy/llvm-symbolizer etc is all contained within llvm/tools, and wouldn't have their own tag, or even one closely related ("llvm" would be the tag they'd come under, which is... less than useful). Separate tags for each tool (possibly with some shared ones for tools which are broadly aliases like llvm-objcopy/llvm-strip and llvm-readelf/llvm-readobj etc) would certainly help me. Bugzilla already has most of these.
I agree with you that my list is not fine-grained enough. I just think it would
be better to add tags as we go rather than copying the current list from bugzilla
and have a lot of tags that we don't need. However, if you think having tags
for the tools would be useful, I would be fine with adding those initially.
Can you write a list of all the specific tags you would like.
(FileCheck and yaml2obj I don’t believe have existing equivalents in bugzilla, but would be/would have been useful to me).
I imagine it would make sense for others like llvm-mca, llvm-lit, etc to exist too, but I haven’t had a need to file or work on bugs in those areas as far as I remember.
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.
> 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?
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.
> 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.
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.
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.
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.
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.
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
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.
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 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.