Richard Smith via llvm-dev
2020-Apr-22 01:50 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > > +1 to James's take > > > > I'd prefer simplicity of implementation over perfection here. > > > > If we end up with two different bug numbering systems, that's a problem > that we will be paying for for many years. It's worth some investment now > to avoid that problem. And it doesn't seem like it really requires much > investment. > > > > Here's another path we could take: > > > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the > bugzilla issues there. Iterate until we're happy, as per James's proposal. > > 2) Sync the forked repository to the llvm repository, delete the llvm > repository, rename "bugs" to "llvm", and make it public. > > > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* > the bugzilla bugs, and we'll have excised the existing github issues that > we want to pretend never existed anyway. > > > > > > I think we've missed an important step in the planning here: we've not > agreed on a set of goals for the transition. Here are mine: > > > > * We end up with one single issue tracking system containing all > issues, both old and new, both open and closed. > > * All links and references to existing bugs still work. > > * We have a single bug numbering system covering all bugs, and old bugs > retain their numbers. > > Why are the bug numbers important?These numbers appear all over our codebase. PR[0-9] appears 3592 times in Clang testcases, plus 45 times in Clang source code and 119 times more as the file names of Clang testcases. If we add inconvenience to looking up all of those, that makes maintenance harder each time someone wants to look one of those up. (That's probably a ~weekly occurrence for me.) Also, bug numbers appear in other bugs. I would assume we're not going to be able to reliably figure out which numbers appearing in a bug are bug numbers during the import process, so those numbers will persist into the github issues world. (In addition, I'm sure multiple groups have their own tracking systems, web pages, documentation, etc. that contain references to LLVM PR numbers. But maybe we shouldn't worry too much about that.) Could you help give some example use cases that require having> a non-intersecting set of bug numbers for bugzilla bugs and github issues? >It makes conversing about bug numbers more difficult if you need to clarify which system you're talking about. As a minor example, we'd have to avoid saying "PR" for the new system in order to avoid confusion, and get used to some new terminology, and probably not use "bug 1234" to describe either system, because that would be ambiguous. None of these individual factors seems like a huge disruption, but they all seem like inconvenience we should prefer to avoid if possible. -Tom> > > > > > It sounds like we don't all agree that the last point is important, but > if we can achieve it without any significant additional cost, why not do so? > > > > Philip > > > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > >> In a previous discussion, one other suggestion had been to migrate > all the bugzilla bugs to a separate initially-private "bug archive" > repository in github. This has a few benefits: > >> 1. If the migration is messed up, the repo can be deleted, and the > process run again, until we get a result we like. > >> 2. The numbering can be fully-controlled. > >> Once the bugs are migrated to /some/ github repository, individual > issues can then be "moved" between repositories, and github will redirect > from the movefrom-repository's bug to the target repository's bug. > >> > >> We could also just have llvm.org/PR### <http://llvm.org/PR#%23%23> > <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue > numbers -- and have it use a file listing the mappings of bugzilla id -> > github id to generate the redirects. (GCC just did this recently for svn > revision number redirections, > https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). > >> > >> Then we could introduce a new naming scheme for github issue > shortlinks. > >> > >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev < > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> > >> Hi, > >> > >> I wanted to continue discussing the plan to migrate from > Bugzilla to Github. > >> It was suggested that I start a new thread and give a > summary of the proposal > >> and what has changed since it was originally proposed in > October. > >> > >> == Here is the original proposal: > >> > >> > http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html > >> > >> == What has changed: > >> > >> * You will be able to subscribe to notifications for a > specific issue > >> labels. We have a proof of concept notification system > using github actions > >> that will be used for this. > >> > >> * Emails will be sent to llvm-bugs when issues are opened > or closed. > >> > >> * We have the initial list of labels: > https://github.com/llvm/llvm-project/labels > >> > >> == Remaining issue: > >> > >> * There is one remaining issue that I don't feel we have > consensus on, > >> and that is what to do with bugs in the existing bugzilla. > Here are some options > >> that we have discussed: > >> > >> 1. Switch to GitHub issues for new bugs only. Bugs filed > in bugzilla that are > >> still active will be updated there until they are closed. > This means that over > >> time the number of active bugs in bugzilla will slowly > decrease as bugs are closed > >> out. Then at some point in the future, all of the bugs > from bugzilla will be archived > >> into their own GitHub repository that is separate from the > llvm-project repo. > >> > >> 2. Same as 1, but also create a migration script that would > allow anyone to > >> manually migrate an active bug from bugzilla to a GitHub > issue in the llvm-project > >> repo. The intention with this script is that it would be > used to migrate high-traffic > >> or important bugs from bugzilla to GitHub to help increase > the visibility of the bug. > >> This would not be used for mass migration of all the bugs. > >> > >> 3. Do a mass bug migration from bugzilla to GitHub and > enable GitHub issues at the same time. > >> Closed or inactive bugs would be archived into their own > GitHub repository, and active bugs > >> would be migrated to the llvm-project repo. > >> > >> > >> Can we preserve the existing bug numbers if we migrate this > way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts > and elsewhere in the world, as well as links to llvm.org/PRxxxxx < > http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers > this would ease the transition pain substantially. > >> > >> > >> The key difference between proposal 1,2 and 3, is when bugs > will be archived from bugzilla > >> to GitHub. Delaying the archiving of bugs (proposals 1 and > 2) means that we can migrate > >> to GitHub issues sooner (within 1-2 weeks), whereas trying > to archive bugs during the > >> transition (proposal 3) will delay the transition for a > while (likely several months) > >> while we evaluate the various solutions for moving bugs > from bugzilla to GitHub. > >> > >> > >> The original proposal was to do 1 or 2, however there were > some concerns raised on the list > >> that having 2 different places to search for bugs for some > period of time would > >> be very inconvenient. So, I would like to restart this > discussion and hopefully we can > >> come to some kind of conclusion about the best way forward. > >> > >> Thanks, > >> Tom > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200421/aaa28075/attachment-0001.html>
Keane, Erich via llvm-dev
2020-Apr-22 01:57 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Humorously, our compiler’s bug tracking database has been replaced 2x+ (plus a couple of JIRA renamings/renumberings)and despite having a mechanism to look up SOME of the old bugs (many got lost in each transition), looking up past bugs is an absolute mess. There is simply a set of magic incantations to get some of our N-1 bugs, and Having shared numbers between bug trackers is the absolute ‘least’ we could do to make the bug tracking database actually usable in the future. We have literal thousands of bug references in source, tests, commit message, and bugs that we literally will never know about again. The result is a bunch of “well, this says it fixes Bug NNNN, so we better not touch it” without having a single hint as to what Bug NNNN was/is. I STRONGLY suggest doing whatever we absolutely can do to make sure that we share numbers. If we have to work with github to make this happen, we should. If we have to spend 2x the time to make sure we do this and do it right, it is ABSOLUTELY worth it. From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Richard Smith via cfe-dev Sent: Tuesday, April 21, 2020 6:51 PM To: Tom Stellard <tstellar at redhat.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at lists.llvm.org>; openmp-dev (openmp-dev at lists.llvm.org) <openmp-dev at lists.llvm.org>; LLDB Dev <lldb-dev at lists.llvm.org> Subject: Re: [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>> wrote: > > +1 to James's take > > I'd prefer simplicity of implementation over perfection here. > > If we end up with two different bug numbering systems, that's a problem that we will be paying for for many years. It's worth some investment now to avoid that problem. And it doesn't seem like it really requires much investment. > > Here's another path we could take: > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the bugzilla issues there. Iterate until we're happy, as per James's proposal. > 2) Sync the forked repository to the llvm repository, delete the llvm repository, rename "bugs" to "llvm", and make it public. > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* the bugzilla bugs, and we'll have excised the existing github issues that we want to pretend never existed anyway. > > > I think we've missed an important step in the planning here: we've not agreed on a set of goals for the transition. Here are mine: > > * We end up with one single issue tracking system containing all issues, both old and new, both open and closed. > * All links and references to existing bugs still work. > * We have a single bug numbering system covering all bugs, and old bugs retain their numbers.Why are the bug numbers important? These numbers appear all over our codebase. PR[0-9] appears 3592 times in Clang testcases, plus 45 times in Clang source code and 119 times more as the file names of Clang testcases. If we add inconvenience to looking up all of those, that makes maintenance harder each time someone wants to look one of those up. (That's probably a ~weekly occurrence for me.) Also, bug numbers appear in other bugs. I would assume we're not going to be able to reliably figure out which numbers appearing in a bug are bug numbers during the import process, so those numbers will persist into the github issues world. (In addition, I'm sure multiple groups have their own tracking systems, web pages, documentation, etc. that contain references to LLVM PR numbers. But maybe we shouldn't worry too much about that.) Could you help give some example use cases that require having a non-intersecting set of bug numbers for bugzilla bugs and github issues? It makes conversing about bug numbers more difficult if you need to clarify which system you're talking about. As a minor example, we'd have to avoid saying "PR" for the new system in order to avoid confusion, and get used to some new terminology, and probably not use "bug 1234" to describe either system, because that would be ambiguous. None of these individual factors seems like a huge disruption, but they all seem like inconvenience we should prefer to avoid if possible. -Tom> > It sounds like we don't all agree that the last point is important, but if we can achieve it without any significant additional cost, why not do so? > > Philip > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: >> In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in github. This has a few benefits: >> 1. If the migration is messed up, the repo can be deleted, and the process run again, until we get a result we like. >> 2. The numbering can be fully-controlled. >> Once the bugs are migrated to /some/ github repository, individual issues can then be "moved" between repositories, and github will redirect from the movefrom-repository's bug to the target repository's bug. >> >> We could also just have llvm.org/PR###<http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue numbers -- and have it use a file listing the mappings of bugzilla id -> github id to generate the redirects. (GCC just did this recently for svn revision number redirections, https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). >> >> Then we could introduce a new naming scheme for github issue shortlinks. >> >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote: >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote: >> >> Hi, >> >> I wanted to continue discussing the plan to migrate from Bugzilla to Github. >> It was suggested that I start a new thread and give a summary of the proposal >> and what has changed since it was originally proposed in October. >> >> == Here is the original proposal: >> >> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html >> >> == What has changed: >> >> * You will be able to subscribe to notifications for a specific issue >> labels. We have a proof of concept notification system using github actions >> that will be used for this. >> >> * Emails will be sent to llvm-bugs when issues are opened or closed. >> >> * We have the initial list of labels: https://github.com/llvm/llvm-project/labels >> >> == Remaining issue: >> >> * There is one remaining issue that I don't feel we have consensus on, >> and that is what to do with bugs in the existing bugzilla. Here are some options >> that we have discussed: >> >> 1. Switch to GitHub issues for new bugs only. Bugs filed in bugzilla that are >> still active will be updated there until they are closed. This means that over >> time the number of active bugs in bugzilla will slowly decrease as bugs are closed >> out. Then at some point in the future, all of the bugs from bugzilla will be archived >> into their own GitHub repository that is separate from the llvm-project repo. >> >> 2. Same as 1, but also create a migration script that would allow anyone to >> manually migrate an active bug from bugzilla to a GitHub issue in the llvm-project >> repo. The intention with this script is that it would be used to migrate high-traffic >> or important bugs from bugzilla to GitHub to help increase the visibility of the bug. >> This would not be used for mass migration of all the bugs. >> >> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues at the same time. >> Closed or inactive bugs would be archived into their own GitHub repository, and active bugs >> would be migrated to the llvm-project repo. >> >> >> Can we preserve the existing bug numbers if we migrate this way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts and elsewhere in the world, as well as links to llvm.org/PRxxxxx<http://llvm.org/PRxxxxx> <http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers this would ease the transition pain substantially. >> >> >> The key difference between proposal 1,2 and 3, is when bugs will be archived from bugzilla >> to GitHub. Delaying the archiving of bugs (proposals 1 and 2) means that we can migrate >> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs during the >> transition (proposal 3) will delay the transition for a while (likely several months) >> while we evaluate the various solutions for moving bugs from bugzilla to GitHub. >> >> >> The original proposal was to do 1 or 2, however there were some concerns raised on the list >> that having 2 different places to search for bugs for some period of time would >> be very inconvenient. So, I would like to restart this discussion and hopefully we can >> come to some kind of conclusion about the best way forward. >> >> Thanks, >> Tom >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/493d2911/attachment.html>
Philip Reames via llvm-dev
2020-Apr-22 16:45 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 4/21/20 6:50 PM, Richard Smith wrote:> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>> > wrote: > > > > +1 to James's take > > > > I'd prefer simplicity of implementation over perfection here. > > > > If we end up with two different bug numbering systems, that's a > problem that we will be paying for for many years. It's worth some > investment now to avoid that problem. And it doesn't seem like it > really requires much investment. > > > > Here's another path we could take: > > > > 1) Fork the llvm repository to a private "bugs" repository. > Mirror the bugzilla issues there. Iterate until we're happy, as > per James's proposal. > > 2) Sync the forked repository to the llvm repository, delete the > llvm repository, rename "bugs" to "llvm", and make it public. > > > > Then we'll have the first N bugs in llvm-project/llvm being > *exactly* the bugzilla bugs, and we'll have excised the existing > github issues that we want to pretend never existed anyway. > > > > > > I think we've missed an important step in the planning here: > we've not agreed on a set of goals for the transition. Here are mine: > > > > * We end up with one single issue tracking system containing > all issues, both old and new, both open and closed. > > * All links and references to existing bugs still work. > > * We have a single bug numbering system covering all bugs, and > old bugs retain their numbers. > > Why are the bug numbers important? > > > These numbers appear all over our codebase. PR[0-9] appears 3592 times > in Clang testcases, plus 45 times in Clang source code and 119 times > more as the file names of Clang testcases. If we add inconvenience to > looking up all of those, that makes maintenance harder each time > someone wants to look one of those up. (That's probably a ~weekly > occurrence for me.)For this use case, a simple script and bulk change to update references in source repo means the numbering can change arbitrarily. ~4k small mechanical changes is just not that much to review for a one time update assuming you trust the number remapping script and are just looking for overly aggressive regex matches. (I don't have any quick fixes for your other mentioned cases.)> > Also, bug numbers appear in other bugs. I would assume we're not going > to be able to reliably figure out which numbers appearing in a bug are > bug numbers during the import process, so those numbers will persist > into the github issues world. > > (In addition, I'm sure multiple groups have their own tracking > systems, web pages, documentation, etc. that contain references to > LLVM PR numbers. But maybe we shouldn't worry too much about that.) > > Could you help give some example use cases that require having > a non-intersecting set of bug numbers for bugzilla bugs and github > issues? > > > It makes conversing about bug numbers more difficult if you need to > clarify which system you're talking about. As a minor example, we'd > have to avoid saying "PR" for the new system in order to avoid > confusion, and get used to some new terminology, and probably not use > "bug 1234" to describe either system, because that would be ambiguous. > None of these individual factors seems like a huge disruption, but > they all seem like inconvenience we should prefer to avoid if possible. > > -Tom > > > > > > It sounds like we don't all agree that the last point is > important, but if we can achieve it without any significant > additional cost, why not do so? > > > > Philip > > > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > >> In a previous discussion, one other suggestion had been to > migrate all the bugzilla bugs to a separate initially-private "bug > archive" repository in github. This has a few benefits: > >> 1. If the migration is messed up, the repo can be deleted, > and the process run again, until we get a result we like. > >> 2. The numbering can be fully-controlled. > >> Once the bugs are migrated to /some/ github repository, > individual issues can then be "moved" between repositories, and > github will redirect from the movefrom-repository's bug to the > target repository's bug. > >> > >> We could also just have llvm.org/PR### > <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url > only for legacy bugzilla issue numbers -- and have it use a file > listing the mappings of bugzilla id -> github id to generate the > redirects. (GCC just did this recently for svn revision number > redirections, > https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). > >> > >> Then we could introduce a new naming scheme for github > issue shortlinks. > >> > >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> > wrote: > >> > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> > wrote: > >> > >> Hi, > >> > >> I wanted to continue discussing the plan to migrate > from Bugzilla to Github. > >> It was suggested that I start a new thread and give > a summary of the proposal > >> and what has changed since it was originally > proposed in October. > >> > >> == Here is the original proposal: > >> > >> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html > >> > >> == What has changed: > >> > >> * You will be able to subscribe to notifications > for a specific issue > >> labels. We have a proof of concept notification > system using github actions > >> that will be used for this. > >> > >> * Emails will be sent to llvm-bugs when issues are > opened or closed. > >> > >> * We have the initial list of labels: > https://github.com/llvm/llvm-project/labels > >> > >> == Remaining issue: > >> > >> * There is one remaining issue that I don't feel we > have consensus on, > >> and that is what to do with bugs in the existing > bugzilla. Here are some options > >> that we have discussed: > >> > >> 1. Switch to GitHub issues for new bugs only. Bugs > filed in bugzilla that are > >> still active will be updated there until they are > closed. This means that over > >> time the number of active bugs in bugzilla will > slowly decrease as bugs are closed > >> out. Then at some point in the future, all of the > bugs from bugzilla will be archived > >> into their own GitHub repository that is separate > from the llvm-project repo. > >> > >> 2. Same as 1, but also create a migration script > that would allow anyone to > >> manually migrate an active bug from bugzilla to a > GitHub issue in the llvm-project > >> repo. The intention with this script is that it > would be used to migrate high-traffic > >> or important bugs from bugzilla to GitHub to help > increase the visibility of the bug. > >> This would not be used for mass migration of all > the bugs. > >> > >> 3. Do a mass bug migration from bugzilla to GitHub > and enable GitHub issues at the same time. > >> Closed or inactive bugs would be archived into > their own GitHub repository, and active bugs > >> would be migrated to the llvm-project repo. > >> > >> > >> Can we preserve the existing bug numbers if we migrate > this way? There are lots of references to "PRxxxxx" in checked in > LLVM artifacts and elsewhere in the world, as well as links to > llvm.org/PRxxxxx <http://llvm.org/PRxxxxx> > <http://llvm.org/PRxxxxx>, and if we can preserve all the issue > numbers this would ease the transition pain substantially. > >> > >> > >> The key difference between proposal 1,2 and 3, is > when bugs will be archived from bugzilla > >> to GitHub. Delaying the archiving of bugs > (proposals 1 and 2) means that we can migrate > >> to GitHub issues sooner (within 1-2 weeks), whereas > trying to archive bugs during the > >> transition (proposal 3) will delay the transition > for a while (likely several months) > >> while we evaluate the various solutions for moving > bugs from bugzilla to GitHub. > >> > >> > >> The original proposal was to do 1 or 2, however > there were some concerns raised on the list > >> that having 2 different places to search for bugs > for some period of time would > >> be very inconvenient. So, I would like to restart > this discussion and hopefully we can > >> come to some kind of conclusion about the best way > forward. > >> > >> Thanks, > >> Tom > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/d26d14e9/attachment-0001.html>
Tom Stellard via llvm-dev
2020-Apr-22 16:45 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 04/21/2020 06:50 PM, Richard Smith wrote:> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>> wrote: > > > > +1 to James's take > > > > I'd prefer simplicity of implementation over perfection here. > > > > If we end up with two different bug numbering systems, that's a problem that we will be paying for for many years. It's worth some investment now to avoid that problem. And it doesn't seem like it really requires much investment. > > > > Here's another path we could take: > > > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the bugzilla issues there. Iterate until we're happy, as per James's proposal. > > 2) Sync the forked repository to the llvm repository, delete the llvm repository, rename "bugs" to "llvm", and make it public. > > > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* the bugzilla bugs, and we'll have excised the existing github issues that we want to pretend never existed anyway. > > > > > > I think we've missed an important step in the planning here: we've not agreed on a set of goals for the transition. Here are mine: > > > > * We end up with one single issue tracking system containing all issues, both old and new, both open and closed. > > * All links and references to existing bugs still work. > > * We have a single bug numbering system covering all bugs, and old bugs retain their numbers. > > Why are the bug numbers important? > > > These numbers appear all over our codebase. PR[0-9] appears 3592 times in Clang testcases, plus 45 times in Clang source code and 119 times more as the file names of Clang testcases. If we add inconvenience to looking up all of those, that makes maintenance harder each time someone wants to look one of those up. (That's probably a ~weekly occurrence for me.) >Having a new number scheme does not mean we have to break all the llvm.org/PR#### links. These could still be used to look up old bugs even if we change bug notation to GH-####.> Also, bug numbers appear in other bugs. I would assume we're not going to be able to reliably figure out which numbers appearing in a bug are bug numbers during the import process, so those numbers will persist into the github issues world. >This is a good point and not something that I had thought of. I think maintaining the bug links in the bugs is something that could be done during the import. e.g replace references to bug# xxxxx with links to llvm.org/PRXXXX. We will have to investigate this more. Thanks, Tom> (In addition, I'm sure multiple groups have their own tracking systems, web pages, documentation, etc. that contain references to LLVM PR numbers. But maybe we shouldn't worry too much about that.) > > Could you help give some example use cases that require having > a non-intersecting set of bug numbers for bugzilla bugs and github issues? > > > It makes conversing about bug numbers more difficult if you need to clarify which system you're talking about. As a minor example, we'd have to avoid saying "PR" for the new system in order to avoid confusion, and get used to some new terminology, and probably not use "bug 1234" to describe either system, because that would be ambiguous. None of these individual factors seems like a huge disruption, but they all seem like inconvenience we should prefer to avoid if possible. > > -Tom > > > > > > It sounds like we don't all agree that the last point is important, but if we can achieve it without any significant additional cost, why not do so? > > > > Philip > > > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > >> In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in github. This has a few benefits: > >> 1. If the migration is messed up, the repo can be deleted, and the process run again, until we get a result we like. > >> 2. The numbering can be fully-controlled. > >> Once the bugs are migrated to /some/ github repository, individual issues can then be "moved" between repositories, and github will redirect from the movefrom-repository's bug to the target repository's bug. > >> > >> We could also just have llvm.org/PR#### <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue numbers -- and have it use a file listing the mappings of bugzilla id -> github id to generate the redirects. (GCC just did this recently for svn revision number redirections, https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). > >> > >> Then we could introduce a new naming scheme for github issue shortlinks. > >> > >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote: > >> > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote: > >> > >> Hi, > >> > >> I wanted to continue discussing the plan to migrate from Bugzilla to Github. > >> It was suggested that I start a new thread and give a summary of the proposal > >> and what has changed since it was originally proposed in October. > >> > >> == Here is the original proposal: > >> > >> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html > >> > >> == What has changed: > >> > >> * You will be able to subscribe to notifications for a specific issue > >> labels. We have a proof of concept notification system using github actions > >> that will be used for this. > >> > >> * Emails will be sent to llvm-bugs when issues are opened or closed. > >> > >> * We have the initial list of labels: https://github.com/llvm/llvm-project/labels > >> > >> == Remaining issue: > >> > >> * There is one remaining issue that I don't feel we have consensus on, > >> and that is what to do with bugs in the existing bugzilla. Here are some options > >> that we have discussed: > >> > >> 1. Switch to GitHub issues for new bugs only. Bugs filed in bugzilla that are > >> still active will be updated there until they are closed. This means that over > >> time the number of active bugs in bugzilla will slowly decrease as bugs are closed > >> out. Then at some point in the future, all of the bugs from bugzilla will be archived > >> into their own GitHub repository that is separate from the llvm-project repo. > >> > >> 2. Same as 1, but also create a migration script that would allow anyone to > >> manually migrate an active bug from bugzilla to a GitHub issue in the llvm-project > >> repo. The intention with this script is that it would be used to migrate high-traffic > >> or important bugs from bugzilla to GitHub to help increase the visibility of the bug. > >> This would not be used for mass migration of all the bugs. > >> > >> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues at the same time. > >> Closed or inactive bugs would be archived into their own GitHub repository, and active bugs > >> would be migrated to the llvm-project repo. > >> > >> > >> Can we preserve the existing bug numbers if we migrate this way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts and elsewhere in the world, as well as links to llvm.org/PRxxxxx <http://llvm.org/PRxxxxx> <http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers this would ease the transition pain substantially. > >> > >> > >> The key difference between proposal 1,2 and 3, is when bugs will be archived from bugzilla > >> to GitHub. Delaying the archiving of bugs (proposals 1 and 2) means that we can migrate > >> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs during the > >> transition (proposal 3) will delay the transition for a while (likely several months) > >> while we evaluate the various solutions for moving bugs from bugzilla to GitHub. > >> > >> > >> The original proposal was to do 1 or 2, however there were some concerns raised on the list > >> that having 2 different places to search for bugs for some period of time would > >> be very inconvenient. So, I would like to restart this discussion and hopefully we can > >> come to some kind of conclusion about the best way forward. > >> > >> Thanks, > >> Tom > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Roman Lebedev via llvm-dev
2020-Apr-22 16:50 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On Wed, Apr 22, 2020 at 7:47 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 04/21/2020 06:50 PM, Richard Smith wrote: > > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>> wrote: > > > > > > +1 to James's take > > > > > > I'd prefer simplicity of implementation over perfection here. > > > > > > If we end up with two different bug numbering systems, that's a problem that we will be paying for for many years. It's worth some investment now to avoid that problem. And it doesn't seem like it really requires much investment. > > > > > > Here's another path we could take: > > > > > > 1) Fork the llvm repository to a private "bugs" repository. Mirror the bugzilla issues there. Iterate until we're happy, as per James's proposal. > > > 2) Sync the forked repository to the llvm repository, delete the llvm repository, rename "bugs" to "llvm", and make it public. > > > > > > Then we'll have the first N bugs in llvm-project/llvm being *exactly* the bugzilla bugs, and we'll have excised the existing github issues that we want to pretend never existed anyway. > > > > > > > > > I think we've missed an important step in the planning here: we've not agreed on a set of goals for the transition. Here are mine: > > > > > > * We end up with one single issue tracking system containing all issues, both old and new, both open and closed. > > > * All links and references to existing bugs still work. > > > * We have a single bug numbering system covering all bugs, and old bugs retain their numbers. > > > > Why are the bug numbers important? > > > > > > These numbers appear all over our codebase. PR[0-9] appears 3592 times in Clang testcases, plus 45 times in Clang source code and 119 times more as the file names of Clang testcases. If we add inconvenience to looking up all of those, that makes maintenance harder each time someone wants to look one of those up. (That's probably a ~weekly occurrence for me.) > > > > Having a new number scheme does not mean we have to break all the > llvm.org/PR#### links. These could still be used to look up old > bugs even if we change bug notation to GH-####. > > > Also, bug numbers appear in other bugs. I would assume we're not going to be able to reliably figure out which numbers appearing in a bug are bug numbers during the import process, so those numbers will persist into the github issues world. > > > > This is a good point and not something that I had thought of. > I think maintaining the bug links in the bugs is something that could > be done during the import. e.g replace references to bug# xxxxx with > links to llvm.org/PRXXXX. We will have to investigate this more.Bug numbers also appear in test file names, and in commit log. Latter you can't adjust.> Thanks, > TomRoman> > (In addition, I'm sure multiple groups have their own tracking systems, web pages, documentation, etc. that contain references to LLVM PR numbers. But maybe we shouldn't worry too much about that.) > > > > Could you help give some example use cases that require having > > a non-intersecting set of bug numbers for bugzilla bugs and github issues? > > > > > > It makes conversing about bug numbers more difficult if you need to clarify which system you're talking about. As a minor example, we'd have to avoid saying "PR" for the new system in order to avoid confusion, and get used to some new terminology, and probably not use "bug 1234" to describe either system, because that would be ambiguous. None of these individual factors seems like a huge disruption, but they all seem like inconvenience we should prefer to avoid if possible. > > > > -Tom > > > > > > > > > > It sounds like we don't all agree that the last point is important, but if we can achieve it without any significant additional cost, why not do so? > > > > > > Philip > > > > > > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: > > >> In a previous discussion, one other suggestion had been to migrate all the bugzilla bugs to a separate initially-private "bug archive" repository in github. This has a few benefits: > > >> 1. If the migration is messed up, the repo can be deleted, and the process run again, until we get a result we like. > > >> 2. The numbering can be fully-controlled. > > >> Once the bugs are migrated to /some/ github repository, individual issues can then be "moved" between repositories, and github will redirect from the movefrom-repository's bug to the target repository's bug. > > >> > > >> We could also just have llvm.org/PR#### <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue numbers -- and have it use a file listing the mappings of bugzilla id -> github id to generate the redirects. (GCC just did this recently for svn revision number redirections, https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). > > >> > > >> Then we could introduce a new naming scheme for github issue shortlinks. > > >> > > >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote: > > >> > > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote: > > >> > > >> Hi, > > >> > > >> I wanted to continue discussing the plan to migrate from Bugzilla to Github. > > >> It was suggested that I start a new thread and give a summary of the proposal > > >> and what has changed since it was originally proposed in October. > > >> > > >> == Here is the original proposal: > > >> > > >> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html > > >> > > >> == What has changed: > > >> > > >> * You will be able to subscribe to notifications for a specific issue > > >> labels. We have a proof of concept notification system using github actions > > >> that will be used for this. > > >> > > >> * Emails will be sent to llvm-bugs when issues are opened or closed. > > >> > > >> * We have the initial list of labels: https://github.com/llvm/llvm-project/labels > > >> > > >> == Remaining issue: > > >> > > >> * There is one remaining issue that I don't feel we have consensus on, > > >> and that is what to do with bugs in the existing bugzilla. Here are some options > > >> that we have discussed: > > >> > > >> 1. Switch to GitHub issues for new bugs only. Bugs filed in bugzilla that are > > >> still active will be updated there until they are closed. This means that over > > >> time the number of active bugs in bugzilla will slowly decrease as bugs are closed > > >> out. Then at some point in the future, all of the bugs from bugzilla will be archived > > >> into their own GitHub repository that is separate from the llvm-project repo. > > >> > > >> 2. Same as 1, but also create a migration script that would allow anyone to > > >> manually migrate an active bug from bugzilla to a GitHub issue in the llvm-project > > >> repo. The intention with this script is that it would be used to migrate high-traffic > > >> or important bugs from bugzilla to GitHub to help increase the visibility of the bug. > > >> This would not be used for mass migration of all the bugs. > > >> > > >> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues at the same time. > > >> Closed or inactive bugs would be archived into their own GitHub repository, and active bugs > > >> would be migrated to the llvm-project repo. > > >> > > >> > > >> Can we preserve the existing bug numbers if we migrate this way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts and elsewhere in the world, as well as links to llvm.org/PRxxxxx <http://llvm.org/PRxxxxx> <http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers this would ease the transition pain substantially. > > >> > > >> > > >> The key difference between proposal 1,2 and 3, is when bugs will be archived from bugzilla > > >> to GitHub. Delaying the archiving of bugs (proposals 1 and 2) means that we can migrate > > >> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs during the > > >> transition (proposal 3) will delay the transition for a while (likely several months) > > >> while we evaluate the various solutions for moving bugs from bugzilla to GitHub. > > >> > > >> > > >> The original proposal was to do 1 or 2, however there were some concerns raised on the list > > >> that having 2 different places to search for bugs for some period of time would > > >> be very inconvenient. So, I would like to restart this discussion and hopefully we can > > >> come to some kind of conclusion about the best way forward. > > >> > > >> Thanks, > > >> Tom > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > > > cfe-dev mailing list > > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > > > > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Richard Smith via llvm-dev
2020-Apr-22 21:35 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev < cfe-dev at lists.llvm.org> wrote:> On 4/21/20 6:50 PM, Richard Smith wrote: > > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: >> > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < >> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> > >> > +1 to James's take >> > >> > I'd prefer simplicity of implementation over perfection here. >> > >> > If we end up with two different bug numbering systems, that's a problem >> that we will be paying for for many years. It's worth some investment now >> to avoid that problem. And it doesn't seem like it really requires much >> investment. >> > >> > Here's another path we could take: >> > >> > 1) Fork the llvm repository to a private "bugs" repository. Mirror the >> bugzilla issues there. Iterate until we're happy, as per James's proposal. >> > 2) Sync the forked repository to the llvm repository, delete the llvm >> repository, rename "bugs" to "llvm", and make it public. >> > >> > Then we'll have the first N bugs in llvm-project/llvm being *exactly* >> the bugzilla bugs, and we'll have excised the existing github issues that >> we want to pretend never existed anyway. >> > >> > >> > I think we've missed an important step in the planning here: we've not >> agreed on a set of goals for the transition. Here are mine: >> > >> > * We end up with one single issue tracking system containing all >> issues, both old and new, both open and closed. >> > * All links and references to existing bugs still work. >> > * We have a single bug numbering system covering all bugs, and old >> bugs retain their numbers. >> >> Why are the bug numbers important? > > > These numbers appear all over our codebase. PR[0-9] appears 3592 times in > Clang testcases, plus 45 times in Clang source code and 119 times more as > the file names of Clang testcases. If we add inconvenience to looking up > all of those, that makes maintenance harder each time someone wants to look > one of those up. (That's probably a ~weekly occurrence for me.) > > For this use case, a simple script and bulk change to update references in > source repo means the numbering can change arbitrarily. ~4k small > mechanical changes is just not that much to review for a one time update > assuming you trust the number remapping script and are just looking for > overly aggressive regex matches. >It's not quite as straightforward as you're suggesting: such a simple script would break a bunch of our CodeGen tests that match mangled names, if the length of any bug identifier changes. A grep for '_Z.*PR[0-9]' indicates that there are at least 254 of those that might need manual updating if we took this path. (I don't have any quick fixes for your other mentioned cases.)>Another case I didn't think of before, but that seems very important: bug numbers appear in commit messages, and are primary context in understanding what the commit is doing and why. [We *could* go on a bulk history editing spree to fix those commit messages up (git filter-branch actually makes this fairly easy) -- but that too would create a little churn as everyone would needs to rebase all their work in progress on the rewritten master, and honestly, that sounds a lot scarier than any of the other things we've considered in this thread :)] Also, bug numbers appear in other bugs. I would assume we're not going to> be able to reliably figure out which numbers appearing in a bug are bug > numbers during the import process, so those numbers will persist into the > github issues world. > > (In addition, I'm sure multiple groups have their own tracking systems, > web pages, documentation, etc. that contain references to LLVM PR numbers. > But maybe we shouldn't worry too much about that.) > > Could you help give some example use cases that require having >> a non-intersecting set of bug numbers for bugzilla bugs and github issues? >> > > It makes conversing about bug numbers more difficult if you need to > clarify which system you're talking about. As a minor example, we'd have to > avoid saying "PR" for the new system in order to avoid confusion, and get > used to some new terminology, and probably not use "bug 1234" to describe > either system, because that would be ambiguous. None of these individual > factors seems like a huge disruption, but they all seem like inconvenience > we should prefer to avoid if possible. > > -Tom >> >> >> > >> > It sounds like we don't all agree that the last point is important, but >> if we can achieve it without any significant additional cost, why not do so? >> > >> > Philip >> > >> > On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote: >> >> In a previous discussion, one other suggestion had been to migrate >> all the bugzilla bugs to a separate initially-private "bug archive" >> repository in github. This has a few benefits: >> >> 1. If the migration is messed up, the repo can be deleted, and the >> process run again, until we get a result we like. >> >> 2. The numbering can be fully-controlled. >> >> Once the bugs are migrated to /some/ github repository, individual >> issues can then be "moved" between repositories, and github will redirect >> from the movefrom-repository's bug to the target repository's bug. >> >> >> >> We could also just have llvm.org/PR### <http://llvm.org/PR#%23%23> >> <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue >> numbers -- and have it use a file listing the mappings of bugzilla id -> >> github id to generate the redirects. (GCC just did this recently for svn >> revision number redirections, >> https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). >> >> >> >> Then we could introduce a new naming scheme for github issue >> shortlinks. >> >> >> >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev < >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> Hi, >> >> >> >> I wanted to continue discussing the plan to migrate from >> Bugzilla to Github. >> >> It was suggested that I start a new thread and give a >> summary of the proposal >> >> and what has changed since it was originally proposed in >> October. >> >> >> >> == Here is the original proposal: >> >> >> >> >> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html >> >> >> >> == What has changed: >> >> >> >> * You will be able to subscribe to notifications for a >> specific issue >> >> labels. We have a proof of concept notification system >> using github actions >> >> that will be used for this. >> >> >> >> * Emails will be sent to llvm-bugs when issues are opened >> or closed. >> >> >> >> * We have the initial list of labels: >> https://github.com/llvm/llvm-project/labels >> >> >> >> == Remaining issue: >> >> >> >> * There is one remaining issue that I don't feel we have >> consensus on, >> >> and that is what to do with bugs in the existing >> bugzilla. Here are some options >> >> that we have discussed: >> >> >> >> 1. Switch to GitHub issues for new bugs only. Bugs filed >> in bugzilla that are >> >> still active will be updated there until they are closed. >> This means that over >> >> time the number of active bugs in bugzilla will slowly >> decrease as bugs are closed >> >> out. Then at some point in the future, all of the bugs >> from bugzilla will be archived >> >> into their own GitHub repository that is separate from the >> llvm-project repo. >> >> >> >> 2. Same as 1, but also create a migration script that >> would allow anyone to >> >> manually migrate an active bug from bugzilla to a GitHub >> issue in the llvm-project >> >> repo. The intention with this script is that it would be >> used to migrate high-traffic >> >> or important bugs from bugzilla to GitHub to help increase >> the visibility of the bug. >> >> This would not be used for mass migration of all the bugs. >> >> >> >> 3. Do a mass bug migration from bugzilla to GitHub and >> enable GitHub issues at the same time. >> >> Closed or inactive bugs would be archived into their own >> GitHub repository, and active bugs >> >> would be migrated to the llvm-project repo. >> >> >> >> >> >> Can we preserve the existing bug numbers if we migrate this >> way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts >> and elsewhere in the world, as well as links to llvm.org/PRxxxxx < >> http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers >> this would ease the transition pain substantially. >> >> >> >> >> >> The key difference between proposal 1,2 and 3, is when >> bugs will be archived from bugzilla >> >> to GitHub. Delaying the archiving of bugs (proposals 1 >> and 2) means that we can migrate >> >> to GitHub issues sooner (within 1-2 weeks), whereas trying >> to archive bugs during the >> >> transition (proposal 3) will delay the transition for a >> while (likely several months) >> >> while we evaluate the various solutions for moving bugs >> from bugzilla to GitHub. >> >> >> >> >> >> The original proposal was to do 1 or 2, however there were >> some concerns raised on the list >> >> that having 2 different places to search for bugs for some >> period of time would >> >> be very inconvenient. So, I would like to restart this >> discussion and hopefully we can >> >> come to some kind of conclusion about the best way forward. >> >> >> >> Thanks, >> >> Tom >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ >> > cfe-dev mailing list >> > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/7a9499db/attachment-0001.html>