From openmp-dev at lists.llvm.org Fri Apr 3 05:18:51 2020 From: openmp-dev at lists.llvm.org (Joseph Schuchart via Openmp-dev) Date: Fri, 3 Apr 2020 14:18:51 +0200 Subject: [Openmp-dev] Status of detached tasks in Clang Message-ID: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> Dear all, I am eager to play around with detached tasks in OpenMP. It seems that support has gone into the runtime about a year ago [1] but even with Clang 10 I get a warning that the detach clause is ignored: $ clang-10 -fopenmp test_detached.c test_detached.c:25:47: warning: extra tokens at the end of '#pragma omp task' are ignored [-Wextra-tokens] #pragma omp task detach(event) The status website lists detached tasks as work in progress [2]. Is there a way to try detached tasks in some experimental version of Clang? Or am I just missing a flag to enable them in the Clang release? Thanks a lot, Joseph [1] https://reviews.llvm.org/D62485 [2] https://clang.llvm.org/docs/OpenMPSupport.html From openmp-dev at lists.llvm.org Sat Apr 4 09:20:59 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Sat, 4 Apr 2020 11:20:59 -0500 Subject: [Openmp-dev] Status of detached tasks in Clang In-Reply-To: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> References: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> Message-ID: <2762c251-b259-a775-98b4-fe5536e3d5de@gmail.com> Hi Joseph, I'm not sure who is working on this but we might be able to figure this out on our bi-weekly call Wednesday. Feel free to call but we should figure this out either way. Apologies for the delay,   Johannes On 4/3/20 7:18 AM, Joseph Schuchart via Openmp-dev wrote: > Dear all, > > I am eager to play around with detached tasks in OpenMP. It seems that > support has gone into the runtime about a year ago [1] but even with > Clang 10 I get a warning that the detach clause is ignored: > > $ clang-10 -fopenmp test_detached.c > test_detached.c:25:47: warning: extra tokens at the end of '#pragma > omp task' are ignored [-Wextra-tokens] >   #pragma omp task detach(event) > > The status website lists detached tasks as work in progress [2]. Is > there a way to try detached tasks in some experimental version of > Clang? Or am I just missing a flag to enable them in the Clang release? > > Thanks a lot, > Joseph > > [1] https://reviews.llvm.org/D62485 > [2] https://clang.llvm.org/docs/OpenMPSupport.html > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Sat Apr 4 17:44:22 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Sat, 4 Apr 2020 19:44:22 -0500 Subject: [Openmp-dev] [RFC] Device Runtime: Directions and Build Requirements Message-ID: <67853901-8983-4e80-5ef1-c3628589fdb2@gmail.com> Hi, I wanted to inform the list of our preliminary plans for the device runtime and plugin.  Please provide feedback and concerns. The overall goal is still to make the device runtime and plugin as independent from the target as possible. While Jon already made excellent progress, we still have "CUDA" files, and we compile certain code actually as "CUDA", e.g., we use __shared__, __device__, ...  I don't think we need to do any of that. OpenMP should be sufficient to create a device runtime on its own, a efficient one when we also use clang extensions where necessary (D74361). A rough idea of how this would look like can be found here:   https://reviews.llvm.org/D77472 In this proof-of-concept we replaced __device__ with   `omp declare target to(NAME)` and __shared__ with   `omp allocate(NAME) allocator(omp_pteam_mem_alloc)`. We should have all the critical parts in-place to compile the runtime only with the CUDA intrinsic known to Clang and the generic atomics for NVIDIA. We wrap the CUDA intrinsics with `omp begin/end declare variant` and can even have all intrinsics (NVIDIA, AMDGPU, ...) in the same file. I'm not sure if the OpenMP driver can emit a pure LLVM-IR device module already but that seems to be doable addition. That IR is linked into the device library bc file as we do it right now which connects everything to the existing infrastructure. Again, please provide feedback and concerns! Cheers,   Johannes From openmp-dev at lists.llvm.org Tue Apr 7 09:59:01 2020 From: openmp-dev at lists.llvm.org (Narayanaswamy, Ravi via Openmp-dev) Date: Tue, 7 Apr 2020 16:59:01 +0000 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Agenda April 08th Message-ID: Reminder that we have a meeting tomorrow at 7:00 AM PST Agenda : - Roll Call - Opens - Development Activity - Implementation of "declare variant" (Johannes : status) - User-defined mapper function status - OpenMP IRBuilder status - Automatic detection of target pragmas without user command line -fopenmp-targets= - Asynchronous offloading. - HIP/CUDA/OpenMP target compilation (discussion led by Greg) - DeviceRTL redesign to support sharing code - OpenMP feature tracking status ( https://clang.llvm.org/docs/OpenMPSupport.html) - LTO for fat binary linking - Support fat static library ......................................................................................................................................... [Blue Jeans] Johannes Doerfert has invited you to a meeting. Join Meeting (Join from computer or phone) ________________________________ Phone Dial-in +1.408.317.9254 (US (San Jose)) +1.866.226.4650 (US Toll Free) (Global Numbers) Meeting ID: 544 112 769 Room System 199.48.152.152 or bjn.vc Meeting ID: 544 112 769 ________________________________ Description: Bi-weekly meeting to discuss OpenMP support in LLVM. ________________________________ Want to test your video connection? https://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4675 bytes Desc: image001.png URL: From openmp-dev at lists.llvm.org Tue Apr 7 17:21:41 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Tue, 7 Apr 2020 19:21:41 -0500 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Agenda April 08th In-Reply-To: References: Message-ID: <95f59d07-e43a-de4b-b774-c760efaadf2c@gmail.com> For the agenda:   - review situation, current and upcoming   - math support in target regions   - prototypes: omp loop, omp metadirective, omp interop On 4/7/20 11:59 AM, Narayanaswamy, Ravi via Openmp-dev wrote: > Reminder that we have a meeting tomorrow at 7:00 AM PST > > > Agenda : > > - Roll Call > > - Opens > > - Development Activity > > - Implementation of "declare variant" (Johannes : status) > > - User-defined mapper function status > > - OpenMP IRBuilder status > > - Automatic detection of target pragmas without user command line -fopenmp-targets= > > - Asynchronous offloading. > > - HIP/CUDA/OpenMP target compilation (discussion led by Greg) > > - DeviceRTL redesign to support sharing code > > - OpenMP feature tracking status ( https://clang.llvm.org/docs/OpenMPSupport.html) > > - LTO for fat binary linking > > - Support fat static library > > ......................................................................................................................................... > [Blue Jeans] > > > Johannes Doerfert has invited you to a meeting. > > > > > Join Meeting > > > > > (Join from computer or phone) > > > > > ________________________________ > > > > Phone Dial-in > +1.408.317.9254 (US (San Jose)) > +1.866.226.4650 (US Toll Free) > (Global Numbers) > > Meeting ID: 544 112 769 > > > Room System > 199.48.152.152 or bjn.vc > > Meeting ID: 544 112 769 > > > ________________________________ > > > > Description: > Bi-weekly meeting to discuss OpenMP support in LLVM. > > > ________________________________ > > > > Want to test your video connection? > https://bluejeans.com/111 > > > > > > > > > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Wed Apr 8 05:02:52 2020 From: openmp-dev at lists.llvm.org (Joseph Schuchart via Openmp-dev) Date: Wed, 8 Apr 2020 14:02:52 +0200 Subject: [Openmp-dev] Status of detached tasks in Clang In-Reply-To: <2762c251-b259-a775-98b4-fe5536e3d5de@gmail.com> References: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> <2762c251-b259-a775-98b4-fe5536e3d5de@gmail.com> Message-ID: Johannes, Alexey, Thanks for the pointers. I will try to call in to the telco tomorrow. In the meantime: I was able to install trunk and run tests with detached tasks. However, every once in a while I end up in an assert inside libomp: OMP: Error #13: Assertion failure at kmp_tasking.cpp(920). The relevant code is in __kmp_task_finish: if (taskdata->td_flags.destructors_thunk) { kmp_routine_entry_t destr_thunk = task->data1.destructors; KMP_ASSERT(destr_thunk); // <- this assert triggers destr_thunk(gtid, task); } My first suspicion is that there is a race condition when one thread fulfills the event while the executing task completes it. I have not been able to spot this issue in the code but maybe someone familiar with it has an idea about what might be going wrong? Thanks, Joseph On 4/4/20 6:20 PM, Johannes Doerfert wrote: > Hi Joseph, > > > I'm not sure who is working on this but we might be able to figure this > out on our bi-weekly call Wednesday. > > Feel free to call but we should figure this out either way. > > > Apologies for the delay, > >   Johannes > > > > On 4/3/20 7:18 AM, Joseph Schuchart via Openmp-dev wrote: >> Dear all, >> >> I am eager to play around with detached tasks in OpenMP. It seems that >> support has gone into the runtime about a year ago [1] but even with >> Clang 10 I get a warning that the detach clause is ignored: >> >> $ clang-10 -fopenmp test_detached.c >> test_detached.c:25:47: warning: extra tokens at the end of '#pragma >> omp task' are ignored [-Wextra-tokens] >>   #pragma omp task detach(event) >> >> The status website lists detached tasks as work in progress [2]. Is >> there a way to try detached tasks in some experimental version of >> Clang? Or am I just missing a flag to enable them in the Clang release? >> >> Thanks a lot, >> Joseph >> >> [1] https://reviews.llvm.org/D62485 >> [2] https://clang.llvm.org/docs/OpenMPSupport.html >> _______________________________________________ >> Openmp-dev mailing list >> Openmp-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev From openmp-dev at lists.llvm.org Wed Apr 8 09:47:34 2020 From: openmp-dev at lists.llvm.org (Joseph Schuchart via Openmp-dev) Date: Wed, 8 Apr 2020 18:47:34 +0200 Subject: [Openmp-dev] Status of detached tasks in Clang In-Reply-To: References: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> <2762c251-b259-a775-98b4-fe5536e3d5de@gmail.com> Message-ID: <7c8de539-4fbb-7992-5976-f20c58ad9962@hlrs.de> Alexey, I am having a hard time trying to come up with a simple reproducer. However, I got hit by an issue that looks similar to what I reported a while ago: https://bugs.llvm.org/show_bug.cgi?id=37671 I updated it with a simpler reproducer. Maybe this issue causes havoc in my actual application and leads to the assert somehow. Maybe someone can take a look at that #37671 now with the simpler test case? I will try and work a reproducer for the assert and report back if I find one. Cheers Joseph On 4/8/20 2:15 PM, Alexey.Bataev wrote: > Hi Joseph, do you have a reproducer? I'll try to reproduce it myself but > it would be better if you could provide one. > > ------------- > Best regards, > Alexey Bataev > > 08.04.2020 8:02 AM, Joseph Schuchart via Openmp-dev пишет: >> Johannes, Alexey, >> >> Thanks for the pointers. I will try to call in to the telco tomorrow. >> >> In the meantime: I was able to install trunk and run tests with >> detached tasks. However, every once in a while I end up in an assert >> inside libomp: >> >> OMP: Error #13: Assertion failure at kmp_tasking.cpp(920). >> >> The relevant code is in __kmp_task_finish: >> >>   if (taskdata->td_flags.destructors_thunk) { >>     kmp_routine_entry_t destr_thunk = task->data1.destructors; >>     KMP_ASSERT(destr_thunk); // <- this assert triggers >>     destr_thunk(gtid, task); >>   } >> >> >> My first suspicion is that there is a race condition when one thread >> fulfills the event while the executing task completes it. I have not >> been able to spot this issue in the code but maybe someone familiar >> with it has an idea about what might be going wrong? >> >> Thanks, >> Joseph >> >> On 4/4/20 6:20 PM, Johannes Doerfert wrote: >>> Hi Joseph, >>> >>> >>> I'm not sure who is working on this but we might be able to figure >>> this out on our bi-weekly call Wednesday. >>> >>> Feel free to call but we should figure this out either way. >>> >>> >>> Apologies for the delay, >>> >>>    Johannes >>> >>> >>> >>> On 4/3/20 7:18 AM, Joseph Schuchart via Openmp-dev wrote: >>>> Dear all, >>>> >>>> I am eager to play around with detached tasks in OpenMP. It seems >>>> that support has gone into the runtime about a year ago [1] but even >>>> with Clang 10 I get a warning that the detach clause is ignored: >>>> >>>> $ clang-10 -fopenmp test_detached.c >>>> test_detached.c:25:47: warning: extra tokens at the end of '#pragma >>>> omp task' are ignored [-Wextra-tokens] >>>>   #pragma omp task detach(event) >>>> >>>> The status website lists detached tasks as work in progress [2]. Is >>>> there a way to try detached tasks in some experimental version of >>>> Clang? Or am I just missing a flag to enable them in the Clang release? >>>> >>>> Thanks a lot, >>>> Joseph >>>> >>>> [1] https://reviews.llvm.org/D62485 >>>> [2] https://clang.llvm.org/docs/OpenMPSupport.html >>>> _______________________________________________ >>>> Openmp-dev mailing list >>>> Openmp-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev >> _______________________________________________ >> Openmp-dev mailing list >> Openmp-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev From openmp-dev at lists.llvm.org Wed Apr 8 12:56:51 2020 From: openmp-dev at lists.llvm.org (Narayanaswamy, Ravi via Openmp-dev) Date: Wed, 8 Apr 2020 19:56:51 +0000 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Minutes April 08th Message-ID: Next Meeting : April 22nd Opens: * Johannes requested developers to participate in reviews to make code robust. * stream pool * Shilei has posted support for fixing the correctness of device synchronization with streams here https://reviews.llvm.org/D77412 * Async support in target library * To support async, the current _tgt_ API for plugin was changed to add an additional argument. https://reviews.llvm.org/D77005 We had agreed previous any exposed API should not change but new APIs will be added and the old API can internally call the new API * AMD plugin * Nice if AMD plugin can be committed to llvm.org. This will enable testing the rewrite of device rtl into common/device specific partition * Greg said they are working on upstreaming the code. This code is currently available for all to access in their github * NEC SX-Aurora plugin * New plugin for NEC SX-Aurora is being developed. Can be found here https://reviews.llvm.org/D76843 * The activity of partitioning device rtl was on hold as Ron was spending quality time as proud dad. Congratulations. * Cuda requirement has been removed * Shared data is supported using declare target and device code using target pragmas. Development Activity:- * Unshackled threads * Shilei presented the design of a prototype to add unshackled threads in openmp runtime to support async target tasks. The presentation is attached There are still issue with how to synchronize with other task and with task wait. Alex mentioned we already have support for detach task for use with target task. We need to create examples and check if they are handled in both the schemes. (unshackled or existing implementation) * Fat Static Library * George has uploaded the support in offload bundler here https://reviews.llvm.org/D74262 * He will be uploading the driver changes. * math support in target regions * Support has been added. * omp loop, omp metadirective, omp interop * Johannes has prototypes implemented omp loop and metadirectives * Was asking if anyone want to participate in omp interop. * Declare variants * Johannes has implemented support for begin/end declare variants. Roll Call : Company Attendees 8-Jan 29-Jan 12-Feb 26-Feb 11-Mar 25-Mar 8-Apr AMD Greg Rodgers x x Ashwin Aji Jan Sjodin x Ron Lieberman x x sameer Sahasrabuddhe Jonathan Chesterfield x x x x x x Andrey Kasaurov ANL Hal Finkel x x Michael Kruse x x x x x Johannes Doerfert x x x x Ye Luo x ARM Andrzej Warzynski x Francesco Petrogalli x x x x IBM Alexandre Eichenberger Carlo Bertolli Kelvin Li x x x Doru Alexey Bataev x x x x x x x Intel Andrey Churbanov x x Ravi Narayanaswamy x x x x x x x Serguei Dmitriev Rajiv Deodhar Lorri Menard Terry Wilmarth Rao, Prem Hansang Bae Xinmin Tian Sirram Aananthakrishnan x x Jeff Hammond x George Rokos x x x x x x x Alex Duran x Micheal Klemm x HPE Deepak Eachempati x x x x x Micron John Leidel Nvidia James Beyer ORNL Graham Lopez Joel Denny x x x x x Geoffroy Vallee Fady Ghanim x x x x x Oscar Hernandez SBU/BNL Lingda Li x Jose Monlsave Vivek Kale x Shilei Tian x TU Darmstadt Lukas Sommer x x x x BrookHavens Abid Malik x Universidata EAFIT Colombia Hamilton Tobon Mosquera x ......................................................................................................................................... [Blue Jeans] Johannes Doerfert has invited you to a meeting. Join Meeting (Join from computer or phone) ________________________________ Phone Dial-in +1.408.317.9254 (US (San Jose)) +1.866.226.4650 (US Toll Free) (Global Numbers) Meeting ID: 544 112 769 Room System 199.48.152.152 or bjn.vc Meeting ID: 544 112 769 ________________________________ Description: Bi-weekly meeting to discuss OpenMP support in LLVM. ________________________________ Want to test your video connection? https://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4675 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unshackled_task.pdf Type: application/pdf Size: 440294 bytes Desc: unshackled_task.pdf URL: From openmp-dev at lists.llvm.org Wed Apr 8 15:52:07 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Wed, 8 Apr 2020 17:52:07 -0500 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Minutes April 08th In-Reply-To: References: Message-ID: <39d64b5a-de79-5e05-e234-b4a0ad09ac9d@gmail.com> Some comments ;) On 4/8/20 2:56 PM, Narayanaswamy, Ravi via Openmp-dev wrote: > Next Meeting : April 22nd > > Opens: > > * Johannes requested developers to participate in reviews to make code robust. > * stream pool > > * Shilei has posted support for fixing the correctness of device synchronization with streams here https://reviews.llvm.org/D77412 > > * Async support in target library > * To support async, the current _tgt_ API for plugin was changed to add an additional argument. https://reviews.llvm.org/D77005 > > We had agreed previous any exposed API should not change but new APIs will be added and the old API can internally call the new API > > * AMD plugin > * Nice if AMD plugin can be committed to llvm.org. This will enable testing the rewrite of device rtl into common/device specific partition Especially the plugin can than be split into common and device specific. > * Greg said they are working on upstreaming the code. This code is currently available for all to access in their github > * NEC SX-Aurora plugin > * New plugin for NEC SX-Aurora is being developed. Can be found here https://reviews.llvm.org/D76843 > * The activity of partitioning device rtl was on hold as Ron was spending quality time as proud dad. Congratulations. Jon, not Ron ;) > * Cuda requirement has been removed Not yet. We have a plan to do so. Work is needed though. > * Shared data is supported using declare target and device code using target pragmas. That's the plan I mention above and in the RFC, yes. > > > > Development Activity:- > > * Unshackled threads > * Shilei presented the design of a prototype to add unshackled threads in openmp runtime to support async target tasks. The presentation is attached > > There are still issue with how to synchronize with other task and with task wait. > > Alex mentioned we already have support for detach task for use with target task. > > We need to create examples and check if they are handled in both the schemes. (unshackled or existing implementation) > > * Fat Static Library > * George has uploaded the support in offload bundler here https://reviews.llvm.org/D74262 > * He will be uploading the driver changes. > * math support in target regions > * Support has been added. > * omp loop, omp metadirective, omp interop > * Johannes has prototypes implemented omp loop and metadirectives > * Was asking if anyone want to participate in omp interop. > * Declare variants > * Johannes has implemented support for begin/end declare variants. > > Roll Call : > > Company > > Attendees > > 8-Jan > > 29-Jan > > 12-Feb > > 26-Feb > > 11-Mar > > 25-Mar > > 8-Apr > > AMD > > > > > > > > > > > > > > > > > > > > Greg Rodgers > > > > x > > > > > > > > > > x > > > > Ashwin Aji > > > > > > > > > > > > > > > > > > Jan Sjodin > > > > x > > > > > > > > > > > > > > Ron Lieberman > > > > x > > > > > > > > > > x > > > > sameer Sahasrabuddhe > > > > > > > > > > > > > > > > > > Jonathan Chesterfield > > x > > x > > x > > x > > x > > x > > > > > > Andrey Kasaurov > > > > > > > > > > > > > > > > ANL > > Hal Finkel > > > > > > > > > > > > x > > x > > > > Michael Kruse > > > > > > x > > x > > x > > x > > x > > > > Johannes Doerfert > > x > > x > > x > > > > > > > > x > > > > Ye Luo > > > > > > > > > > > > > > x > > ARM > > Andrzej Warzynski > > > > x > > > > > > > > > > > > > > Francesco Petrogalli > > > > x > > x > > x > > > > x > > > > IBM > > Alexandre Eichenberger > > > > > > > > > > > > > > > > > > Carlo Bertolli > > > > > > > > > > > > > > > > > > Kelvin Li > > x > > > > > > x > > x > > > > > > > > Doru > > > > > > > > > > > > > > > > > > Alexey Bataev > > x > > x > > x > > x > > x > > x > > x > > Intel > > Andrey Churbanov > > > > > > > > > > > > x > > x > > > > Ravi Narayanaswamy > > x > > x > > x > > x > > x > > x > > x > > > > Serguei Dmitriev > > > > > > > > > > > > > > > > > > Rajiv Deodhar > > > > > > > > > > > > > > > > > > Lorri Menard > > > > > > > > > > > > > > > > > > Terry Wilmarth > > > > > > > > > > > > > > > > > > Rao, Prem > > > > > > > > > > > > > > > > > > Hansang Bae > > > > > > > > > > > > > > > > > > Xinmin Tian > > > > > > > > > > > > > > > > > > Sirram Aananthakrishnan > > > > > > x > > x > > > > > > > > > > Jeff Hammond > > > > > > > > > > > > x > > > > > > George Rokos > > x > > x > > x > > x > > x > > x > > x > > > > Alex Duran > > > > > > > > > > > > > > x > > > > Micheal Klemm > > > > > > > > x > > > > > > > > HPE > > Deepak Eachempati > > > > x > > x > > x > > > > x > > x > > Micron > > John Leidel > > > > > > > > > > > > > > > > Nvidia > > James Beyer > > > > > > > > > > > > > > > > ORNL > > Graham Lopez > > > > > > > > > > > > > > > > > > Joel Denny > > > > x > > > > x > > x > > x > > x > > > > Geoffroy Vallee > > > > > > > > > > > > > > > > > > Fady Ghanim > > x > > x > > x > > x > > x > > > > > > > > Oscar Hernandez > > > > > > > > > > > > > > > > SBU/BNL > > Lingda Li > > > > > > x > > > > > > > > > > > > Jose Monlsave > > > > > > > > > > > > > > > > > > Vivek Kale > > > > x > > > > > > > > > > > > > > Shilei Tian > > > > > > > > > > > > > > x > > TU Darmstadt > > Lukas Sommer > > x > > > > x > > x > > > > > > x > > BrookHavens > > Abid Malik > > x > > > > > > > > > > > > > > Universidata EAFIT Colombia > > Hamilton Tobon Mosquera > > > > > > > > > > > > > > x > > > > ......................................................................................................................................... > [Blue Jeans] > > > Johannes Doerfert has invited you to a meeting. > > > > > Join Meeting > > > > > (Join from computer or phone) > > > > > ________________________________ > > > > Phone Dial-in > +1.408.317.9254 (US (San Jose)) > +1.866.226.4650 (US Toll Free) > (Global Numbers) > > Meeting ID: 544 112 769 > > > Room System > 199.48.152.152 or bjn.vc > > Meeting ID: 544 112 769 > > > ________________________________ > > > > Description: > Bi-weekly meeting to discuss OpenMP support in LLVM. > > > ________________________________ > > > > Want to test your video connection? > https://bluejeans.com/111 > > > > > > > > > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Thu Apr 9 02:42:11 2020 From: openmp-dev at lists.llvm.org (Joseph Schuchart via Openmp-dev) Date: Thu, 9 Apr 2020 11:42:11 +0200 Subject: [Openmp-dev] Status of detached tasks in Clang In-Reply-To: References: <399bc298-f23e-b543-03bf-c25f13906ade@hlrs.de> <2762c251-b259-a775-98b4-fe5536e3d5de@gmail.com> <7c8de539-4fbb-7992-5976-f20c58ad9962@hlrs.de> Message-ID: Ahh, good point! The issue with local variables seems to be specific to untied tasks. I removed all untied tasks in my application but every other run I'm still hitting asserts in the same code path (when calling omp_fulfill_event): Assertion failure at kmp_tasking.cpp(3744): taskdata->td_flags.complete == 1. Assertion failure at kmp_tasking.cpp(710): taskdata->td_flags.executing == 0. Although they are different assertions they are probably just different symptoms of the same problem. My use-case involves MPI (and an experimental extension) so it is hard to boil that down to a simple reproducer. Just so I know whether it's a direction to investigate: could these asserts be triggered by calling omp_fulfill_event twice on the same event? Or is that case handled explicitly? I don't know how this could happen in my current setup but if it's not handled by libomp I will investigate that possibility. Thanks for the help so far :) Cheers Joseph On 4/8/20 6:54 PM, Alexey.Bataev wrote: > Hi Joseph, I see, you have an issue with untied tasks. Yes, they are not > fully supported in terms of capturing local variables. > > ------------- > Best regards, > Alexey Bataev > > 08.04.2020 12:47 PM, Joseph Schuchart пишет: >> Alexey, >> >> I am having a hard time trying to come up with a simple reproducer. >> However, I got hit by an issue that looks similar to what I reported a >> while ago: >> https://bugs.llvm.org/show_bug.cgi?id=37671 >> >> I updated it with a simpler reproducer. Maybe this issue causes havoc >> in my actual application and leads to the assert somehow. Maybe >> someone can take a look at that #37671 now with the simpler test case? >> >> I will try and work a reproducer for the assert and report back if I >> find one. >> >> Cheers >> Joseph >> >> On 4/8/20 2:15 PM, Alexey.Bataev wrote: >>> Hi Joseph, do you have a reproducer? I'll try to reproduce it myself >>> but it would be better if you could provide one. >>> >>> ------------- >>> Best regards, >>> Alexey Bataev >>> >>> 08.04.2020 8:02 AM, Joseph Schuchart via Openmp-dev пишет: >>>> Johannes, Alexey, >>>> >>>> Thanks for the pointers. I will try to call in to the telco tomorrow. >>>> >>>> In the meantime: I was able to install trunk and run tests with >>>> detached tasks. However, every once in a while I end up in an assert >>>> inside libomp: >>>> >>>> OMP: Error #13: Assertion failure at kmp_tasking.cpp(920). >>>> >>>> The relevant code is in __kmp_task_finish: >>>> >>>>   if (taskdata->td_flags.destructors_thunk) { >>>>     kmp_routine_entry_t destr_thunk = task->data1.destructors; >>>>     KMP_ASSERT(destr_thunk); // <- this assert triggers >>>>     destr_thunk(gtid, task); >>>>   } >>>> >>>> >>>> My first suspicion is that there is a race condition when one thread >>>> fulfills the event while the executing task completes it. I have not >>>> been able to spot this issue in the code but maybe someone familiar >>>> with it has an idea about what might be going wrong? >>>> >>>> Thanks, >>>> Joseph >>>> >>>> On 4/4/20 6:20 PM, Johannes Doerfert wrote: >>>>> Hi Joseph, >>>>> >>>>> >>>>> I'm not sure who is working on this but we might be able to figure >>>>> this out on our bi-weekly call Wednesday. >>>>> >>>>> Feel free to call but we should figure this out either way. >>>>> >>>>> >>>>> Apologies for the delay, >>>>> >>>>>    Johannes >>>>> >>>>> >>>>> >>>>> On 4/3/20 7:18 AM, Joseph Schuchart via Openmp-dev wrote: >>>>>> Dear all, >>>>>> >>>>>> I am eager to play around with detached tasks in OpenMP. It seems >>>>>> that support has gone into the runtime about a year ago [1] but >>>>>> even with Clang 10 I get a warning that the detach clause is ignored: >>>>>> >>>>>> $ clang-10 -fopenmp test_detached.c >>>>>> test_detached.c:25:47: warning: extra tokens at the end of >>>>>> '#pragma omp task' are ignored [-Wextra-tokens] >>>>>>   #pragma omp task detach(event) >>>>>> >>>>>> The status website lists detached tasks as work in progress [2]. >>>>>> Is there a way to try detached tasks in some experimental version >>>>>> of Clang? Or am I just missing a flag to enable them in the Clang >>>>>> release? >>>>>> >>>>>> Thanks a lot, >>>>>> Joseph >>>>>> >>>>>> [1] https://reviews.llvm.org/D62485 >>>>>> [2] https://clang.llvm.org/docs/OpenMPSupport.html >>>>>> _______________________________________________ >>>>>> Openmp-dev mailing list >>>>>> Openmp-dev at lists.llvm.org >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev >>>> _______________________________________________ >>>> Openmp-dev mailing list >>>> Openmp-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev From openmp-dev at lists.llvm.org Wed Apr 15 16:42:22 2020 From: openmp-dev at lists.llvm.org (Tanya Lattner via Openmp-dev) Date: Wed, 15 Apr 2020 16:42:22 -0700 Subject: [Openmp-dev] 2020 US LLVM Developers' Meeting - September 28-29 Message-ID: The LLVM Foundation is pleased to announce the 14th annual LLVM Developers’ Meeting in the Bay Area on September 28-29 in San Jose, CA. We will have additional events on September 27th in the afternoon/evening which be announced when available. The LLVM Developers' Meeting is a bi-annual 2 day gathering of the entire LLVM Project community. The conference is organized by the LLVM Foundation and many volunteers within the LLVM community. Developers and users of LLVM, Clang, and related subprojects will enjoy attending interesting talks, impromptu discussions, and networking with the many members of our community. Whether you are a new to the LLVM project or a long time member, there is something for each attendee. Given the current situation regarding COVID-19, we feel it is best to be totally transparent with our planning process. We are closely monitoring the news regarding restrictions on travel and large gatherings and also following the World Health Organization's advice. It takes about 9-12 months of planning for our developers’ meetings and given we do not know the situation in September, we are moving forward with the hope that it will be safe to host our event. What can you expect at a LLVM Developers' Meeting? Technical Talks: These 20-30 minute talks cover all topics from core infrastructure talks, to project's using LLVM's infrastructure. Attendees will take away technical information that could be pertinent to their project or general interest. Tutorials: Tutorials are 50 minute sessions that dive down deep into a technical topic. Expect in depth examples and explanations. Lightning Talks: These are fast 5 minute talks that give you a taste of a project or topic. Attendees will hear a wide range of topics and probably leave you wanting to learn more. Panels: Panel sessions are guided discussions about a specific topic. The panel consists of ~3 developers who discuss a topic through prepared questions from a moderator. The audience is also given the opportunity to ask questions of the panel. Birds of a Feather: Large round table discussions with a more formal directed discussion. Student Research Competition: Students present their research using LLVM or related subprojects. These are usually 20 minute technical presentations with Q&A. The audience will vote at the end for the winning presentation and paper. Poster Session: An hour long session where selected posters are on display for attendees to ask questions and discuss. Round Table Discussions: Informal and impromptu discussions on a specific topic. During the conference there are set time slots where groups can organize to discuss a problem or topic. Evening Reception (September 28): After a full day of technical talks and discussions, join your fellow attendees for an evening reception to continue the conversation and meet even more attendees. What types of people attend? • Active developers of projects in the LLVM Umbrella (LLVM core, Clang, LLDB, libc++, compiler_rt, klee, lld, etc). • Anyone interested in using these as part of another project. • Students and Researchers • Compiler, programming language, and runtime enthusiasts. • Those interested in using compiler and toolchain technology in novel and interesting ways. More information regarding call for papers, registration, travel grants,etc, will be coming in the next month. For future announcements or questions: Please sign up for the LLVM Developers’ Meeting mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Thu Apr 16 15:42:59 2020 From: openmp-dev at lists.llvm.org (Rokos, Georgios via Openmp-dev) Date: Thu, 16 Apr 2020 22:42:59 +0000 Subject: [Openmp-dev] long double in AST Message-ID: Hi all, I was looking at the following function from clang/lib/AST/ASTContext.cpp:1649 /// getFloatTypeSemantics - Return the APFloat 'semantics' for the specified /// scalar floating point type. const llvm::fltSemantics &ASTContext::getFloatTypeSemantics(QualType T) const { switch (T->castAs()->getKind()) { default: llvm_unreachable("Not a floating point type!"); case BuiltinType::Float16: case BuiltinType::Half: return Target->getHalfFormat(); case BuiltinType::Float: return Target->getFloatFormat(); case BuiltinType::Double: return Target->getDoubleFormat(); case BuiltinType::LongDouble: if (getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice) return AuxTarget->getLongDoubleFormat(); return Target->getLongDoubleFormat(); case BuiltinType::Float128: if (getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice) return AuxTarget->getFloat128Format(); return Target->getFloat128Format(); } } For long double and float128, when we are on the device we get the "semantics" for those datatypes from AuxTarget instead of Target. Why is that? Thanks! George -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Thu Apr 16 16:16:35 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Thu, 16 Apr 2020 18:16:35 -0500 Subject: [Openmp-dev] long double in AST In-Reply-To: References: Message-ID: <87916bb5-23d4-4b9b-9322-af08a1110529@gmail.com> Hi George, Because the target might not support them but we need the size anyway. The reasons is unavailable types in a structure which is mapped. While we could bail, the user might have a hard time breaking the structure apart. Instead, we allow it as long as you don't interact with the type as such. You basically have an array of bytes on the device side, not a thing with an unavailable type. Does this make sense? You should also take a look at this conversation: https://reviews.llvm.org/D74387 I explained my preferred solution, and he shortcomings of the OpenMP implementation so far. FWIW, I was hoping Intel would now implement this for SYCL and OpenMP in the same way :) WDYT? Cheers,   Johannes On 4/16/20 5:42 PM, Rokos, Georgios via Openmp-dev wrote: > Hi all, > > I was looking at the following function from clang/lib/AST/ASTContext.cpp:1649 > > /// getFloatTypeSemantics - Return the APFloat 'semantics' for the specified > /// scalar floating point type. > const llvm::fltSemantics &ASTContext::getFloatTypeSemantics(QualType T) const { >   switch (T->castAs()->getKind()) { >   default: >     llvm_unreachable("Not a floating point type!"); >   case BuiltinType::Float16: >   case BuiltinType::Half: >     return Target->getHalfFormat(); >   case BuiltinType::Float:      return Target->getFloatFormat(); >   case BuiltinType::Double:     return Target->getDoubleFormat(); >   case BuiltinType::LongDouble: >     if (getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice) >       return AuxTarget->getLongDoubleFormat(); >     return Target->getLongDoubleFormat(); >   case BuiltinType::Float128: >     if (getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice) >       return AuxTarget->getFloat128Format(); >     return Target->getFloat128Format(); >   } > } > > For long double and float128, when we are on the device we get the "semantics" for those datatypes from AuxTarget instead of Target. Why is that? > > Thanks! > George > > > > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev From openmp-dev at lists.llvm.org Fri Apr 17 12:43:17 2020 From: openmp-dev at lists.llvm.org (Jon Chesterfield via Openmp-dev) Date: Fri, 17 Apr 2020 20:43:17 +0100 Subject: [Openmp-dev] RFC: Refactor CGOpenMPRuntimeNVPTX into a base class Message-ID: Specifically, into CGOpenMPRuntimeGPU with an implementation for nvptx which behaves identically to today, and an implementation for amdgcn. The out of tree amdgcn/openmp repo uses branches within nvptx to target amdgcn. That works but it's not pretty. The base + two implementations would give us a working openmp front end for amdgcn fairly quickly, as a stop gap until target regions is ready. It may also be useful to have tregions and the old codegen simultaneously available for testing. This RFC is mostly searching for someone to review a slightly dull NFC to nvptx which opens the door for a second GPU target. Anyone broadly willing? Thanks, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Sat Apr 18 03:37:54 2020 From: openmp-dev at lists.llvm.org (ichbinwu via Openmp-dev) Date: Sat, 18 Apr 2020 12:37:54 +0200 Subject: [Openmp-dev] OpenMP GPU shared memory Message-ID: <190015da-1d84-e303-f29e-57125e3c36cb@gmail.com> hello everybody, I have a question about GPU shared memory in the OpenMP implementation in LLVM. In the paper by Grinberg, Bertolli, and Haque (Hands on with OpenMP 4.5 and Unified Memory: Developing Applications for IBM's Hybrid CPU + GPU systems (Part II), IWOMP 2017) I found "3. Clang's Extension for OpenMP 4.5 for device On-chip Memory Allocation" and learnt that the GPU shared memory can be used in a tricky manner with OpenMP directives. In order to find the compiler limit for this static memory allocation I looked at the source code files under `openmp`. It seems the relevant files are: 1. openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h * commit: 197b7b24 * line: DS_Slot_Size = 256, 2. openmp/libomptarget/deviceRTLs/common/omptarget.h * commit: d0b9ed5c * line: char Data[DS_Slot_Size]; My questions are: 1. Is the hard-coded limit for GPU shared memory 256 Bytes or (256 * 4) Bytes? Because I see the comment in `openmp/libomptarget/deviceRTLs/common/omptarget.h` // Additional master slot type which is initialized with the default master slot // size of 4 bytes. 2. Could we enlarge this limit to, e.g. 512 Bytes or even 1024 Bytes? Concerning the hardware specification of green GPUs, if we assume the shared memory per multiprocessor is 48 KB and at most 32 thread blocks (or contention groups) reside on one multiprocessor, this limit can be as large as 1536 Bytes, isn't it? 3. How could we check/verify that the static memory allocation is on GPU shared memory (not on global memory), when an OpenMP source file is compiled by Clang/LLVM? My current approach is to look at the generated assembly code (`-S`), which is not really convenient. It would be good, if the compiler can print some message or give a short report during compilation. Thank you in advance! Best wishes! Xin From openmp-dev at lists.llvm.org Sat Apr 18 16:11:07 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Sat, 18 Apr 2020 18:11:07 -0500 Subject: [Openmp-dev] OpenMP GPU shared memory In-Reply-To: <190015da-1d84-e303-f29e-57125e3c36cb@gmail.com> References: <190015da-1d84-e303-f29e-57125e3c36cb@gmail.com> Message-ID: Hi Xin, I think what you found is some runtime code that lives in shared memory. This is not to be confused with user data put into shared memory. To do the latter, you can use the allocate directive, e.g., int Global[32]; #pragma omp allocate(Global) allocator(omp_pteam_mem_alloc) Wrt. to the feedback I don't think there is anything in place. You could use nvprof if you run it maybe. However, I agree we should have a flag that provides better information. I hope this helps. Cheers,   Johannes On 4/18/20 5:37 AM, ichbinwu via Openmp-dev wrote: > hello everybody, > > I have a question about GPU shared memory in the OpenMP implementation > in LLVM. > > In the paper by Grinberg, Bertolli, and Haque (Hands on with OpenMP > 4.5 and Unified Memory: Developing Applications for IBM's Hybrid CPU + > GPU systems (Part II), IWOMP 2017) I found "3. Clang's Extension for > OpenMP 4.5 for device On-chip Memory Allocation" and learnt that the > GPU shared memory can be used in a tricky manner with OpenMP > directives. In order to find the compiler limit for this static memory > allocation I looked at the source code files under `openmp`. It seems > the relevant files are: > > 1. openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h >     * commit: 197b7b24 >     * line: DS_Slot_Size = 256, > > 2. openmp/libomptarget/deviceRTLs/common/omptarget.h >     * commit: d0b9ed5c >     * line: char Data[DS_Slot_Size]; > > My questions are: > > 1. Is the hard-coded limit for GPU shared memory 256 Bytes or (256 * > 4) Bytes? Because I see the comment in > `openmp/libomptarget/deviceRTLs/common/omptarget.h` > > // Additional master slot type which is initialized with the default > master slot > // size of 4 bytes. > > 2. Could we enlarge this limit to, e.g. 512 Bytes or even 1024 Bytes? > Concerning the hardware specification of green GPUs, if we assume the > shared memory per multiprocessor is 48 KB and at most 32 thread blocks > (or contention groups) reside on one multiprocessor, this limit can be > as large as 1536 Bytes, isn't it? > > 3. How could we check/verify that the static memory allocation is on > GPU shared memory (not on global memory), when an OpenMP source file > is compiled by Clang/LLVM? My current approach is to look at the > generated assembly code (`-S`), which is not really convenient. It > would be good, if the compiler can print some message or give a short > report during compilation. > > Thank you in advance! > > Best wishes! > > Xin > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Mon Apr 20 12:30:38 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Mon, 20 Apr 2020 12:30:38 -0700 Subject: [Openmp-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] Message-ID: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> 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. 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 From openmp-dev at lists.llvm.org Mon Apr 20 12:49:35 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Mon, 20 Apr 2020 12:49:35 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < 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, 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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Mon Apr 20 13:01:32 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Mon, 20 Apr 2020 13:01:32 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: On 04/20/2020 12:49 PM, Richard Smith wrote: > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , and if we can preserve all the issue numbers this would ease the transition pain substantially. > For all 3 proposals we want to be able to preserver the llvm.org/PRxxxx links so that they continue to provide useful information. Eventually once bugzilla is shut down, those links would point to an issue somewhere in GitHub. We don't have a solution for this today and this is one of the reasons why proposal 3 will take so long to implement, because we need to solve this problem before we start any kind of transition. This is also the reason why proposals 1 and 2 were originally favored, because they allow us to transition to GitHub issues for new bugs sooner, while still maintaining the PRxxxx links in bugzilla. This gives us time to work out a good long-term solution to maintaining the links without further delaying the transition to GitHub issues. -Tom > > 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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > From openmp-dev at lists.llvm.org Mon Apr 20 13:25:49 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Mon, 20 Apr 2020 23:25:49 +0300 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: > 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, and if we can preserve all the issue numbers this would ease the transition pain substantially. Well... I hate to say this, but quite unlikely. Unfortunately, there were significant changes in GitHub opensource team and these days they are much less responsive than they used to be during our github migration. I asked this question several times, and unfortunately, there is no answer. I will certainly keep trying. The problem here is there is no way to assign / control issue numbers at all. They are just automatically assigned in sequential order. While it might be possible to utilize this while migrating everything to, say, a special archive project on GitHub, we will not be able to control the numbers assigned should we migrate the issues one-by-one or just move from archive to main project. So, the only viable way seems to be plain big mapping from bugzilla to github issue numbers without anything simple like "llvm.org/PRxxxxxx becomes https://github.com/llvm/llvm-project/issues/xxxxxx". -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Mon Apr 20 13:32:36 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Mon, 20 Apr 2020 23:32:36 +0300 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: Just to clarify a bit: what I wanted to say is that it's unlikely that we will be able to ensure that bugzilla issue numbers after migration would coincide with github issue numbers. And therefore proper mapping will be necessary. And this mapping would be more complex than just rewriting the URL. On Mon, Apr 20, 2020 at 11:25 PM Anton Korobeynikov wrote: > > > 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, and if we can preserve all the issue numbers this would ease the transition pain substantially. > Well... I hate to say this, but quite unlikely. Unfortunately, there > were significant changes in GitHub opensource team and these days they > are much less responsive than they used to be during our github > migration. I asked this question several times, and unfortunately, > there is no answer. I will certainly keep trying. > > The problem here is there is no way to assign / control issue numbers > at all. They are just automatically assigned in sequential order. > While it might be possible to utilize this while migrating everything > to, say, a special archive project on GitHub, we will not be able to > control the numbers assigned should we migrate the issues one-by-one > or just move from archive to main project. > > So, the only viable way seems to be plain big mapping from bugzilla to > github issue numbers without anything simple like "llvm.org/PRxxxxxx > becomes https://github.com/llvm/llvm-project/issues/xxxxxx". > > > -- > With best regards, Anton Korobeynikov > Department of Statistical Modelling, Saint Petersburg State University -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Mon Apr 20 13:40:20 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Mon, 20 Apr 2020 13:40:20 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: 210 issues have been filed on github so far. That's negligible compared to the total number we have, so a minor additional effort for those seems acceptable if we can't actually clean them out and reuse the numbers. So suppose we start with bugzilla issue #211 and migrate the issues to github one at a time, in order. That would preserve the existing bug numbering and all existing bugs, other than those first 210. For those 210, I'd suggest we file new issues on github, and add comments to github issue 1-210 indicating they've been migrated and the new issue number. (I'd be inclined to delete as much contents from those issues as possible and retain only the redirect to the new number.) Would that work? On Mon, 20 Apr 2020 at 13:33, Anton Korobeynikov via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Just to clarify a bit: what I wanted to say is that it's unlikely > that we will be able to ensure that bugzilla issue numbers after > migration would coincide with github issue numbers. And therefore > proper mapping will be necessary. And this mapping would be more > complex than just rewriting the URL. > > > On Mon, Apr 20, 2020 at 11:25 PM Anton Korobeynikov > wrote: > > > > > 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, and if we > can preserve all the issue numbers this would ease the transition pain > substantially. > > Well... I hate to say this, but quite unlikely. Unfortunately, there > > were significant changes in GitHub opensource team and these days they > > are much less responsive than they used to be during our github > > migration. I asked this question several times, and unfortunately, > > there is no answer. I will certainly keep trying. > > > > The problem here is there is no way to assign / control issue numbers > > at all. They are just automatically assigned in sequential order. > > While it might be possible to utilize this while migrating everything > > to, say, a special archive project on GitHub, we will not be able to > > control the numbers assigned should we migrate the issues one-by-one > > or just move from archive to main project. > > > > So, the only viable way seems to be plain big mapping from bugzilla to > > github issue numbers without anything simple like "llvm.org/PRxxxxxx > > becomes https://github.com/llvm/llvm-project/issues/xxxxxx". > > > > > > -- > > With best regards, Anton Korobeynikov > > Department of Statistical Modelling, Saint Petersburg State University > > > > -- > With best regards, Anton Korobeynikov > Department of Statistical Modelling, Saint Petersburg State University > _______________________________________________ > 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: From openmp-dev at lists.llvm.org Mon Apr 20 13:57:00 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Mon, 20 Apr 2020 23:57:00 +0300 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: > If we are reasonably certain that no one would be opening new issues on GitHub while the migration is running... And pull requests (the numbering is common for issues and pull requests) as well. And we cannot disable pull requests at all. And I'm afraid the issues will need to be opened as well during the migration. And now the real problem: should an "extra" pull request or issue intervene in the migration there is no way to "reset" the counter besides deleting the project and creating it once again. We could only sacrifice some bugzilla issues to restore the numbering... -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Mon Apr 20 14:25:17 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Mon, 20 Apr 2020 14:25:17 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: On Mon, 20 Apr 2020 at 13:57, Anton Korobeynikov via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > If we are reasonably certain that no one would be opening new issues on > GitHub while the migration is running... > And pull requests (the numbering is common for issues and pull > requests) as well. And we cannot disable pull requests at all. And I'm > afraid the issues will need to be opened as well during the migration. > And now the real problem: should an "extra" pull request or issue > intervene in the migration there is no way to "reset" the counter > besides deleting the project and creating it once again. We could only > sacrifice some bugzilla issues to restore the numbering... > We can edit summaries and comments, presumably by API calls as well as by the web UI. So how about this: Step 1: Preallocate sufficient github issue numbers. Make a bot account and with it file empty placeholder issues until we have N issues total, where N is the number of bugzilla bugs. Step 2: Shut down the ability to file new bugzilla bugs, double-check we have enough placeholder bugs, then open up github for new issue submissions. Change llvm.org/PRxxxxx to redirect to github for xxxxx's higher than the transition point. Step 3a: For each issue filed by the bot account, sync that bug's contents to the bugzilla entry: copy across the subject, all the comments, tags, and so on. Step 3b: For each issue not filed by the bot account whose number is that of a bugzilla entry, file a new github bug and sync it with the bugzilla bug then add a tracking comment to the github bug saying what the new number is. All we would need to do before we switch systems is steps 1 and 2. The data import can be done incrementally with no time constraints. Once transition is complete, we can change llvm.org/PRxxxxx (and existing bugzilla links, since I'm sure they exist in the wild too) to redirect to github, and shut down our bugzilla instance. If new PRs are filed during step 1, we get new "problem" issue numbers, which we deal with in the same way as the 210 existing github issue numbers. -- > With best regards, Anton Korobeynikov > Department of Statistical Modelling, Saint Petersburg State University > _______________________________________________ > 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: From openmp-dev at lists.llvm.org Mon Apr 20 21:28:52 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Mon, 20 Apr 2020 21:28:52 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: On 04/20/2020 09:15 PM, Mehdi AMINI wrote: > Hi, > > How is the user workflow to file bugs? Do we have some sort of template? Do they have to pick a label? > We don't have any templates defined yet, we need someone to volunteer to do this. Users would not be required to pick a label, they would either use a template which would add the label automatically or pick a label they felt was relevant. -Tom > Thanks, > > -- > Mehdi > > > On Mon, Apr 20, 2020 at 12:30 PM Tom Stellard via llvm-dev > 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. > > > 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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > From openmp-dev at lists.llvm.org Mon Apr 20 21:57:54 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Mon, 20 Apr 2020 21:57:54 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <919872d0-d79a-9975-0791-be4ab0d7bb42@redhat.com> On 04/20/2020 04:08 PM, James Y Knight 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. > This seems like a good approach to me. > We could also just have llvm.org/PR### 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). > Would we even need a mapping file for this if we are able to get bugzilla id N to be archived to GitHub issue id N? -Tom > 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 > wrote: > > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 > 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 > From openmp-dev at lists.llvm.org Tue Apr 21 01:01:39 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Tue, 21 Apr 2020 11:01:39 +0300 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <919872d0-d79a-9975-0791-be4ab0d7bb42@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <919872d0-d79a-9975-0791-be4ab0d7bb42@redhat.com> Message-ID: > On 04/20/2020 04:08 PM, James Y Knight 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. > This seems like a good approach to me. This might work, yes. There are some limitations as well, this is why I'm very cautious here. See https://docs.google.com/document/d/1byEcbsxF3pL-HGGd_K6axdh87tbcsuJK3Dp6ThxGjKA/edit for some list. > > > We could also just have llvm.org/PR### 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). > > > > Would we even need a mapping file for this if we are able to get bugzilla id N > to be archived to GitHub issue id N? > > -Tom > > > 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 > wrote: > > > > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 > > 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Tue Apr 21 01:39:23 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Tue, 21 Apr 2020 11:39:23 +0300 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: Hi James, > Please could we replace the "llvm-tools" with a single label for each LLVM tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc etc). Sorry, I missed the subcomponents for the tools when I did the migration of the labels. Will add them! -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Tue Apr 21 10:46:53 2020 From: openmp-dev at lists.llvm.org (Narayanaswamy, Ravi via Openmp-dev) Date: Tue, 21 Apr 2020 17:46:53 +0000 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Agenda April 22nd Message-ID: Reminder that we have a meeting tomorrow at 7:00 AM PST Agenda : - Roll Call - Opens - Long double support - Development Activity - Async support - User-defined mapper function status - OpenMP IRBuilder status - Automatic detection of target pragmas without user command line -fopenmp-targets= - Asynchronous offloading. - HIP/CUDA/OpenMP target compilation (discussion led by Greg) - DeviceRTL redesign to support sharing code - OpenMP feature tracking status ( https://clang.llvm.org/docs/OpenMPSupport.html) - LTO for fat binary linking - Support fat static library ......................................................................................................................................... [Blue Jeans] Johannes Doerfert has invited you to a meeting. Join Meeting (Join from computer or phone) ________________________________ Phone Dial-in +1.408.317.9254 (US (San Jose)) +1.866.226.4650 (US Toll Free) (Global Numbers) Meeting ID: 544 112 769 Room System 199.48.152.152 or bjn.vc Meeting ID: 544 112 769 ________________________________ Description: Bi-weekly meeting to discuss OpenMP support in LLVM. ________________________________ Want to test your video connection? https://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4675 bytes Desc: image001.png URL: From openmp-dev at lists.llvm.org Tue Apr 21 10:52:38 2020 From: openmp-dev at lists.llvm.org (David Blaikie via Openmp-dev) Date: Tue, 21 Apr 2020 10:52:38 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <919872d0-d79a-9975-0791-be4ab0d7bb42@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <919872d0-d79a-9975-0791-be4ab0d7bb42@redhat.com> Message-ID: All things being equal, I'd prefer Richard Smith's proposal that doesn't involve needing a new/old numbering scheme, but lets us keep a single numbering/redirection (& I doubt we need the first 200 bugs in any case - has anyone referred to bugs that early in the last 5 years, say? But wouldn't mind if they were copied in with different numbers/some kind of redirection (but hey, if we can rewrite bug contents - we could always move the existing 200 bugs (but I guess some are pull requests and we can't totally rewrite those into bugs?) up into the new numbering range once the necessary numbers are reserved)). But I understand the single numbering preserving option is likely more complicated/costly & thus not an equal candidate - just my minor preference. On Mon, Apr 20, 2020 at 9:58 PM Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 04/20/2020 04:08 PM, James Y Knight 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. > > > > This seems like a good approach to me. > > > We could also just have llvm.org/PR### < > http://llvm.org/PR###> 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). > > > > Would we even need a mapping file for this if we are able to get bugzilla > id N > to be archived to GitHub issue id N? > > -Tom > > > 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 > wrote: > > > > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < > 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 > > 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 > > > > _______________________________________________ > 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: From openmp-dev at lists.llvm.org Tue Apr 21 11:03:54 2020 From: openmp-dev at lists.llvm.org (Philip Reames via Openmp-dev) Date: Tue, 21 Apr 2020 11:03:54 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: +1 to James's take I'd prefer simplicity of implementation over perfection here. 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### 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 > > wrote: > > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > > 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 , 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 > 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 > > > _______________________________________________ > 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: From openmp-dev at lists.llvm.org Tue Apr 21 14:19:40 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Tue, 21 Apr 2020 14:19:40 -0700 Subject: [Openmp-dev] LLVM 10.0.1 Release Schedule Message-ID: <68063a6d-d950-59cf-8762-f6f4ca167133@redhat.com> Hi, Here is the proposed 10.0.1 release schedule. If there are no objections, I'll put it on the website. May 18: 10.0.1-rc1 Jun 18: 10.0.1-rc2 Jun 25: 10.0.1-final -Tom From openmp-dev at lists.llvm.org Tue Apr 21 14:47:39 2020 From: openmp-dev at lists.llvm.org (Joel E. Denny via Openmp-dev) Date: Tue, 21 Apr 2020 17:47:39 -0400 Subject: [Openmp-dev] buildbot failure in LLVM on openmp-gcc-x86_64-linux-debian In-Reply-To: <20200421212019.6C8C710A0790@lab.llvm.org> References: <20200421212019.6C8C710A0790@lab.llvm.org> Message-ID: It appears that 'libomp :: ompt/tasks/dependences.c' has a race. I don't know how my patches would have caused the failure below, and it passed at the next build. Joel On Tue, Apr 21, 2020 at 5:20 PM wrote: > The Buildbot has detected a new failure on builder > openmp-gcc-x86_64-linux-debian while building openmp. > Full details are available at: > > http://lab.llvm.org:8011/builders/openmp-gcc-x86_64-linux-debian/builds/6842 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: gribozavr4 > > Build Reason: scheduler > Build Source Stamp: [branch master] > 5f6aa9680c19534a382cb652178e0ff6edbe78de > Blamelist: Joel E. Denny > > BUILD FAILED: failed test-openmp > > sincerely, > -The Buildbot > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Tue Apr 21 15:36:09 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Tue, 21 Apr 2020 15:36:09 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < 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. 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### 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> wrote: > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < >> 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, 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 >>> 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 >> > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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: From openmp-dev at lists.llvm.org Tue Apr 21 16:05:06 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Tue, 21 Apr 2020 18:05:06 -0500 Subject: [Openmp-dev] buildbot failure in LLVM on openmp-gcc-x86_64-linux-debian In-Reply-To: References: <20200421212019.6C8C710A0790@lab.llvm.org> Message-ID: <7d0b40a2-b1aa-88d1-0047-b1b6ab3ac26c@gmail.com> A lot of these tests seem to have races or at least timing dependent behavior. We recently had to disable some already. Our test infrastructure needs two improve here. We need to run them multiple times if they are necessarily timing dependent. We also should check if the ones that are need to be, e.g., if they all pass when we force single threaded execution (or if failing is what we want them to do). Long story short, I doubt you caused the failure but if you are interested you could look into improvements in this area ;) On 4/21/20 4:47 PM, Joel E. Denny via Openmp-dev wrote: > It appears that 'libomp :: ompt/tasks/dependences.c' has a race. I > don't know how my patches would have caused the failure below, and it > passed at the next build. > > Joel > > > On Tue, Apr 21, 2020 at 5:20 PM wrote: > >> The Buildbot has detected a new failure on builder >> openmp-gcc-x86_64-linux-debian while building openmp. >> Full details are available at: >> >> http://lab.llvm.org:8011/builders/openmp-gcc-x86_64-linux-debian/builds/6842 >> >> Buildbot URL: http://lab.llvm.org:8011/ >> >> Buildslave for this Build: gribozavr4 >> >> Build Reason: scheduler >> Build Source Stamp: [branch master] >> 5f6aa9680c19534a382cb652178e0ff6edbe78de >> Blamelist: Joel E. Denny >> >> BUILD FAILED: failed test-openmp >> >> sincerely, >> -The Buildbot >> >> >> >> > > _______________________________________________ > Openmp-dev mailing list > Openmp-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Tue Apr 21 16:29:42 2020 From: openmp-dev at lists.llvm.org (Joel E. Denny via Openmp-dev) Date: Tue, 21 Apr 2020 19:29:42 -0400 Subject: [Openmp-dev] buildbot failure in LLVM on openmp-gcc-x86_64-linux-debian In-Reply-To: <7d0b40a2-b1aa-88d1-0047-b1b6ab3ac26c@gmail.com> References: <20200421212019.6C8C710A0790@lab.llvm.org> <7d0b40a2-b1aa-88d1-0047-b1b6ab3ac26c@gmail.com> Message-ID: Thanks for the info! I'll keep this in mind. Joel On Tue, Apr 21, 2020 at 7:06 PM Johannes Doerfert < johannesdoerfert at gmail.com> wrote: > A lot of these tests seem to have races or at least timing dependent > behavior. > > We recently had to disable some already. Our test infrastructure needs two > improve here. > > We need to run them multiple times if they are necessarily timing > dependent. > > We also should check if the ones that are need to be, e.g., if they all > pass when we force > > single threaded execution (or if failing is what we want them to do). > > > Long story short, I doubt you caused the failure but if you are interested > you could look > > into improvements in this area ;) > > > > On 4/21/20 4:47 PM, Joel E. Denny via Openmp-dev wrote: > > It appears that 'libomp :: ompt/tasks/dependences.c' has a race. I > don't know how my patches would have caused the failure below, and it > passed at the next build. > > Joel > > > On Tue, Apr 21, 2020 at 5:20 PM wrote: > > > The Buildbot has detected a new failure on builder > openmp-gcc-x86_64-linux-debian while building openmp. > Full details are available at: > http://lab.llvm.org:8011/builders/openmp-gcc-x86_64-linux-debian/builds/6842 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: gribozavr4 > > Build Reason: scheduler > Build Source Stamp: [branch master] > 5f6aa9680c19534a382cb652178e0ff6edbe78de > Blamelist: Joel E. Denny > > BUILD FAILED: failed test-openmp > > sincerely, > -The Buildbot > > > > > > > _______________________________________________ > Openmp-dev mailing listOpenmp-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Tue Apr 21 16:37:03 2020 From: openmp-dev at lists.llvm.org (Philip Reames via Openmp-dev) Date: Tue, 21 Apr 2020 16:37:03 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <2f772200-955b-81d3-f9cd-c4b31b722181@philipreames.com> On 4/21/20 3:36 PM, Richard Smith wrote: > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev > > 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. I used to think this was super important, but I've now been through a couple of conversions which didn't provide a 1-to-1 mapping.  It's annoying for about 6 months, and after that, you basically forget it happened.  As long as old bugs are searchable in the new system, and you can find the new ID from the old system, the exact identifier isn't as important. Anyways, this is all subjective and I'm certainty not volunteering to work on this, so IMHO my own opinion doesn't really count.  :) > > 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. > > 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### >> 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 >> > wrote: >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev >> > 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 , 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 >> 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 >> >> >> _______________________________________________ >> 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: From openmp-dev at lists.llvm.org Tue Apr 21 17:00:17 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Tue, 21 Apr 2020 17:00:17 -0700 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> 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 > 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? Could you help give some example use cases that require having a non-intersecting set of bug numbers for bugzilla bugs and github issues? -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### 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 > wrote: >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 >> 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 >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > From openmp-dev at lists.llvm.org Tue Apr 21 18:50:55 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Tue, 21 Apr 2020 18:50:55 -0700 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: 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 > 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### > 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 > wrote: > >> > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < > 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 > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > 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: From openmp-dev at lists.llvm.org Tue Apr 21 19:42:15 2020 From: openmp-dev at lists.llvm.org (Johannes Doerfert via Openmp-dev) Date: Tue, 21 Apr 2020 21:42:15 -0500 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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 > 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? Could you help give some example use cases that require having > a non-intersecting set of bug numbers for bugzilla bugs and github issues? While I have no experience in bugzilla or github tooling, the two step process described by Richard doesn't seem to be very complicated. As mentioned by others, we have commits and tests (and sometimes source files) that explicitly mention bug numbers. I do regularly look up bugs from a decade ago to determine if a test or some code still has relevance or not. If PR3214 can be one of two bugs, it does not only increase lookup time but also add confusion to everyone involved. Cheers,   Johannes > -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### 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 > wrote: >>> >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 >>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 From openmp-dev at lists.llvm.org Wed Apr 22 00:22:43 2020 From: openmp-dev at lists.llvm.org (Dimitry Andric via Openmp-dev) Date: Wed, 22 Apr 2020 09:22:43 +0200 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: <0F91F123-0CFC-466D-A8D7-0B0307A56005@andric.com> Since Bugzilla numbers are all under 50,000 (at least for now:), can't we simply bump the GitHub issue/pull request numbers to 50,000, and start from there? Then it would be easy to identify: < 50000 means Bugzilla, >= 50000 means GitHub. Now somebody's only gotta find a way to file 50000-200 bogus GitHub tickets. :) (Or ask GitHub support to bump the number synthetically.) -Dimitry > On 22 Apr 2020, at 09:10, James Henderson via cfe-dev wrote: > > Similar to other people's experiences, I've worked on a common code base that supported three different platforms, and each platform used a different bugzilla with it's own numbering scheme. I regularly came across references to "BZ123456" with no indication as to which of the three systems that referred to. This would often mean having to go to each in turn and seeing if the corresponding bug looked like it had anything to do with the related topic. Fortunately, given that there were many other things using the same bugzilla instances, this was usually pretty clear, but not always. Typos in bug numbers sometimes made things even harder, since you had to spend three times as long trying to guess. > > In other words +1 to using unique numbers, however we do it. > > On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev > wrote: > > On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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 >> 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? Could you help give some example use cases that require having > > a non-intersecting set of bug numbers for bugzilla bugs and github issues? > > > While I have no experience in bugzilla or github tooling, the two step > process described by Richard doesn't seem to be very complicated. > > > As mentioned by others, we have commits and tests (and sometimes source > files) that explicitly mention bug numbers. I do regularly look up bugs > from a decade ago to determine if a test or some code still has > relevance or not. If PR3214 can be one of two bugs, it does not only > increase lookup time but also add confusion to everyone involved. > > > Cheers, > > Johannes > > > > > -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### > 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 >> wrote: > >>> > >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev >> 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 >, 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 > > >>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: From openmp-dev at lists.llvm.org Wed Apr 22 04:54:17 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Wed, 22 Apr 2020 14:54:17 +0300 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> <0F91F123-0CFC-466D-A8D7-0B0307A56005@andric.com> Message-ID: Hi Konrad, Thanks for the scripts – look useful! For the record, here is the result of previous experiments https://github.com/asl/llvm-bugzilla/issues On Wed, Apr 22, 2020 at 2:21 PM Konrad Kleine via cfe-dev wrote: > > I wanted to try importing llvm bugs into a fresh github repo and here's my result so far (import is still running): https://github.com/kwk/test-llvm-bz-import-4 . I've written the scripts (https://github.com/kwk/bz2gh) myself because I wanted to remain in control and don't make my life more complicated than it needs to be. The README.md describes in great length what's imported and how. For now I import the bugzillas just as placeholder issues. Then I lock those issues in github to avoid messing with them. Before I created labels based on /. Those are assigned to each issue. It should give a good start to at least reserve all github #IDs so they map 1:1 to LLVM BZs. > > On Wed, 22 Apr 2020 at 09:23, Dimitry Andric via cfe-dev wrote: >> >> Since Bugzilla numbers are all under 50,000 (at least for now:), can't we simply bump the GitHub issue/pull request numbers to 50,000, and start from there? >> >> Then it would be easy to identify: < 50000 means Bugzilla, >= 50000 means GitHub. >> >> Now somebody's only gotta find a way to file 50000-200 bogus GitHub tickets. :) (Or ask GitHub support to bump the number synthetically.) >> >> -Dimitry >> >> On 22 Apr 2020, at 09:10, James Henderson via cfe-dev wrote: >> >> Similar to other people's experiences, I've worked on a common code base that supported three different platforms, and each platform used a different bugzilla with it's own numbering scheme. I regularly came across references to "BZ123456" with no indication as to which of the three systems that referred to. This would often mean having to go to each in turn and seeing if the corresponding bug looked like it had anything to do with the related topic. Fortunately, given that there were many other things using the same bugzilla instances, this was usually pretty clear, but not always. Typos in bug numbers sometimes made things even harder, since you had to spend three times as long trying to guess. >> >> In other words +1 to using unique numbers, however we do it. >> >> On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev wrote: >>> >>> >>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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 > 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? Could you help give some example use cases that require having >>> > a non-intersecting set of bug numbers for bugzilla bugs and github issues? >>> >>> >>> While I have no experience in bugzilla or github tooling, the two step >>> process described by Richard doesn't seem to be very complicated. >>> >>> >>> As mentioned by others, we have commits and tests (and sometimes source >>> files) that explicitly mention bug numbers. I do regularly look up bugs >>> from a decade ago to determine if a test or some code still has >>> relevance or not. If PR3214 can be one of two bugs, it does not only >>> increase lookup time but also add confusion to everyone involved. >>> >>> >>> Cheers, >>> >>> Johannes >>> >>> >>> >>> > -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### 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 > wrote: >>> >>> >>> >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 >>> >>> 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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Wed Apr 22 05:31:45 2020 From: openmp-dev at lists.llvm.org (Anton Korobeynikov via Openmp-dev) Date: Wed, 22 Apr 2020 15:31:45 +0300 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: GitHub also supports custom prefixes for the issues. However, here is another limitation: the prefix must be at least 3 letters, so we cannot, for example, autolink PR1234 issues. Already asked whether this restriction could be lifted. On Wed, Apr 22, 2020 at 3:15 PM James Y Knight via llvm-dev wrote: > > GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and also supports "GH-NNN". We'll want to switch to one of those schemes, so that automatic linking works properly. So, in that case, PR1234 == legacy issue, #1234 or GH-1234 == new issue. > > (See https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls) > > On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev wrote: >> >> >> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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 > 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? Could you help give some example use cases that require having >> > a non-intersecting set of bug numbers for bugzilla bugs and github issues? >> >> >> While I have no experience in bugzilla or github tooling, the two step >> process described by Richard doesn't seem to be very complicated. >> >> >> As mentioned by others, we have commits and tests (and sometimes source >> files) that explicitly mention bug numbers. I do regularly look up bugs >> from a decade ago to determine if a test or some code still has >> relevance or not. If PR3214 can be one of two bugs, it does not only >> increase lookup time but also add confusion to everyone involved. >> >> >> Cheers, >> >> Johannes >> >> >> >> > -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### 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 > wrote: >> >>> >> >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 >> >>> 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 >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University From openmp-dev at lists.llvm.org Wed Apr 22 09:45:28 2020 From: openmp-dev at lists.llvm.org (Philip Reames via Openmp-dev) Date: Wed, 22 Apr 2020 09:45:28 -0700 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: On 4/21/20 6:50 PM, Richard Smith wrote: > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > > 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 > > >> > 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### > 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 > > >> > wrote: > >> > >>         On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > > >> > 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 > , 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 > > > >> 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 > >> > >> > >>     _______________________________________________ > >>     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 > > > > > > > > _______________________________________________ > > 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: From openmp-dev at lists.llvm.org Wed Apr 22 09:45:50 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Wed, 22 Apr 2020 09:45:50 -0700 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: On 04/21/2020 06:50 PM, Richard Smith wrote: > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > 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 >> 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#### 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 >> wrote: > >> > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev >> 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 , 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 > > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > 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 > From openmp-dev at lists.llvm.org Wed Apr 22 09:50:39 2020 From: openmp-dev at lists.llvm.org (Roman Lebedev via Openmp-dev) Date: Wed, 22 Apr 2020 19:50:39 +0300 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: On Wed, Apr 22, 2020 at 7:47 PM Tom Stellard via llvm-dev wrote: > > On 04/21/2020 06:50 PM, Richard Smith wrote: > > On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev > 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 >> 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, > Tom Roman > > (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#### 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 >> wrote: > > >> > > >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev >> 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 , 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 > > > >> 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 > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev From openmp-dev at lists.llvm.org Wed Apr 22 09:53:57 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Wed, 22 Apr 2020 09:53:57 -0700 Subject: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <630ecb32-63a9-769d-725e-48c9c41c2619@redhat.com> 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 > 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. > I would be nervous about deleting the current repo for any reason. It may work, but the implications of doing this are unclear. I think an alternative would be to copy the existing GitHub issues from the llvm repo into the private "bugs" repository after the bugzilla import is done. Then we can just copy and overwrite any existing GitHub issues in the llvm repository with the bugzilla data for the corresponding ID. e.g. For GitHub issue #1, delete all the comments and replace them with the comments (and other data) from bugzilla issue #1. -Tom > 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. > > 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### 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 > wrote: >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev > 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 , 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 >> 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 >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > From openmp-dev at lists.llvm.org Wed Apr 22 12:43:25 2020 From: openmp-dev at lists.llvm.org (Narayanaswamy, Ravi via Openmp-dev) Date: Wed, 22 Apr 2020 19:43:25 +0000 Subject: [Openmp-dev] OpenMP in LLVM Multi-company Telecom Meeting Minutes April 22nd Message-ID: Next Meeting : May 6th Opens: * non-contiguous target update Chi Chun present a mechanism to support non-contiguous target update. (See attached slides target_update_noncontiguous) Involves adding a new map type OMP_TGT_MAPTYPE_DESCRIPTOR to libomptarget. Passing an array of descriptor as the "args" argument and the dimension in "args_size" argument. HPE will be implementing as everybody agreed on the design. OpenMP is not clear when an update is requested with size larger than the size on the device. Need to get clarification from OpenMP. * Long double support Currently during target compilation the aux target size is used for long double case BuiltinType::LongDouble: if (getLangOpts().OpenMP && getLangOpts().OpenMPIsDevice) return AuxTarget->getLongDoubleFormat(); What if the host was compiled with to use a different size eg: -mlong-double-64, then the size on host and target will be different. We agreed that above code should use target size and its users/compilers responsibility to make sure the same flag -mlong-double-64 is used during host and target compilation. Johannes requested that SYCLl should use OpenMP method of implementation of only erroring of unsupported device types if only used in device code. If only host code uses it then it should not error. * Async Offloading. Ravi presented async offloading using detached tasks. (See attached slides openmp_async_offload) Johannes said the implementation by Shilei is similar except the servicing of these async target tasks are done by specially created detached threads. The detached threads schedule the async target task and wait for it to be completed without effecting other openmp threads. When will these detached threads be created : Options are they can be created during startup or when needed. How many detached threads are created : As many as the number of simultaneous parallel offload required. Theorical max could be number of queues/pipes. What is the cost of these threads : Will have a better picture in couple of weeks are implementing and running performance measurements. Roll Call : Company Attendees 8-Jan 29-Jan 12-Feb 26-Feb 11-Mar 25-Mar 8-Apr 22-Apr AMD Greg Rodgers x x x Ashwin Aji Jan Sjodin x x Ron Lieberman x x x Sameer Sahasrabuddhe Rich Bleikamp x Jonathan Chesterfield x x x x x x x Andrey Kasaurov ANL Hal Finkel x x x Michael Kruse x x x x x Johannes Doerfert x x x x x Ye Luo x ARM Andrzej Warzynski x Francesco Petrogalli x x x x IBM Alexandre Eichenberger Carlo Bertolli Kelvin Li x x x x x Doru Alexey Bataev x x x x x x x Intel Andrey Churbanov x x x Ravi Narayanaswamy x x x x x x x x Serguei Dmitriev Rajiv Deodhar Lorri Menard Terry Wilmarth Rao, Prem Hansang Bae Xinmin Tian Sirram Aananthakrishnan x x Jeff Hammond x George Rokos x x x x x x x x Alex Duran x Micheal Klemm x HPE Deepak Eachempati x x x x x x Sunil Shrestha x Chi Chun Chen x Micron John Leidel Nvidia James Beyer ORNL Graham Lopez Joel Denny x x x x x x Geoffroy Vallee Fady Ghanim x x x x x Oscar Hernandez SBU/BNL Lingda Li x Jose Monlsave Vivek Kale x Shilei Tian x TU Darmstadt Lukas Sommer x x x x BrookHavens Abid Malik x Universidata EAFIT Colombia Hamilton Tobon Mosquera x x ......................................................................................................................................... [Blue Jeans] Johannes Doerfert has invited you to a meeting. Join Meeting (Join from computer or phone) ________________________________ Phone Dial-in +1.408.317.9254 (US (San Jose)) +1.866.226.4650 (US Toll Free) (Global Numbers) Meeting ID: 544 112 769 Room System 199.48.152.152 or bjn.vc Meeting ID: 544 112 769 ________________________________ Description: Bi-weekly meeting to discuss OpenMP support in LLVM. ________________________________ Want to test your video connection? https://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4675 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: target_update_noncontiguous.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 48005 bytes Desc: target_update_noncontiguous.pptx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openmp_async_offload.pdf Type: application/pdf Size: 131573 bytes Desc: openmp_async_offload.pdf URL: From openmp-dev at lists.llvm.org Wed Apr 22 14:35:02 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Wed, 22 Apr 2020 14:35:02 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: 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 > 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### >> 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 > wrote: >> >> >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < >> 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 >> >> 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 >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> > >> > _______________________________________________ >> > 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: From openmp-dev at lists.llvm.org Wed Apr 22 14:52:29 2020 From: openmp-dev at lists.llvm.org (Philip Reames via Openmp-dev) Date: Wed, 22 Apr 2020 14:52:29 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <025f8b66-e8ed-ca4f-8509-afd03b9a754f@redhat.com> Message-ID: <8e49c44c-2277-0a75-ab65-8c10e841ff58@philipreames.com> On 4/22/20 2:35 PM, Richard Smith wrote: > On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev > > wrote: > > On 4/21/20 6:50 PM, Richard Smith wrote: > >> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev >> > 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 >> >> > >> 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. We have an auto-updater for most llc scripts, but point taken.  My main point was this was one time, not that the one time was trivial. > > (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 :)] Agreed, history rewrite as a solution here should be rejected out of hand.  :) > >> 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### >> 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 > >> > >> wrote: >> >> >> >>         On Mon, 20 Apr 2020 at 12:31, Tom Stellard via >> llvm-dev > >> > >> 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 >> , 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 >> > >> >> 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 >> >> >> >> >> >>  _______________________________________________ >> >>     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 >> > >> > >> > >> > _______________________________________________ >> > 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: From openmp-dev at lists.llvm.org Fri Apr 24 12:03:32 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Fri, 24 Apr 2020 12:03:32 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <7754a710-d773-28a7-69cd-e4246a5a7a8f@redhat.com> On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). > As such I don't think we should migrate clangd to a using the monorepo bugtracker. Email subscription to a label is better than nothing, but worse than a separate repo. > Removing the clangd label from the monorepo bugtracker seems like the simplest thing, though I'm happy to work on auto-moving bugs if that's better. > > (I'd suggest considering the same for other subprojects, though I know that's not a popular opinion here) I think it's important for everything in the monorepo to use the same bug tracker. There are advantages to having code in the monorepo (e.g. free updates for API changes, a more consistent build experience, etc.). But there are also costs, as you have pointed out, like having to use a less than ideal bug tracker. It's really up to sub-projects to make the decision about whether these benefits are worth the costs. The flang developers have just gone through this process and have had to make some sacrifices to get the code in, but ultimately felt the sacrifices were worth it. I think it hurts the ability of developers and users to collaborate effectively, if the infrastructure for the project is spread across too many different places. And good collaboration is key for a project of this size with some many tightly connected components. Getting back to the proposal we are discussing. Do you have any specific feedback for improvements that might help make it align better with the kind of experience the clangd users and developers are looking for? - Tom From openmp-dev at lists.llvm.org Fri Apr 24 14:36:17 2020 From: openmp-dev at lists.llvm.org (Richard Smith via Openmp-dev) Date: Fri, 24 Apr 2020 14:36:17 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <7754a710-d773-28a7-69cd-e4246a5a7a8f@redhat.com> Message-ID: On Fri, 24 Apr 2020 at 14:13, Sam McCall via cfe-dev wrote: > On Fri, Apr 24, 2020 at 9:03 PM Tom Stellard wrote: > >> On 04/24/2020 03:24 AM, Sam McCall wrote: >> > clangd's experience using github issues to track bugs (in a separate >> repo) has been very positive, and I'm glad you're pushing on this! >> > >> > Part of this has been that our issue tracker has been scoped to our >> subproject only, which is a scope that the tool works well for (on the user >> and developer side). >> > As such I don't think we should migrate clangd to a using the monorepo >> bugtracker. Email subscription to a label is better than nothing, but worse >> than a separate repo. >> > Removing the clangd label from the monorepo bugtracker seems like the >> simplest thing, though I'm happy to work on auto-moving bugs if that's >> better. >> > >> > (I'd suggest considering the same for other subprojects, though I know >> that's not a popular opinion here) >> >> I think it's important for everything in the monorepo to use the same bug >> tracker. >> >> There are advantages to having code in the monorepo (e.g. free >> updates for API changes, a more consistent build experience, etc.). >> But there are also costs, as you have pointed out, like having to use >> a less than ideal bug tracker. It's really up to sub-projects >> to make the decision about whether these benefits are worth the costs. >> The flang developers have just gone through this process and have >> had to make some sacrifices to get the code in, but ultimately felt the >> sacrifices were worth it. >> >> I think it hurts the ability of developers and users to collaborate >> effectively, >> if the infrastructure for the project is spread across too many different >> places. >> And good collaboration is key for a project of this size with some many >> tightly >> connected components. >> > (sorry, I should probably not tilt at this windmill. More on-topic stuff > below, I promise!) > Right, and I think having a single-project view of the LLVM organization > is a mistake: it's a graph of projects, some are highly connected and some > are not. > The monorepo has a strong technical reason: the graph is connected and > accepting a CI boundary anywhere is expensive in the absence of stable APIs. > But this is much less true for bug tracking systems: the cost to crossing > boundaries is smaller. > For clangd, the benefit of sharing a tracker with clang AST+Sema is less > than the cost of sharing a tracker with clang codegen, LLVM proper, LLD, > flang, MLIR, ... (and the opposite is true for source control/CI). > Anyway, this is going to depend on what part(s) of the project graph you > touch: people connected to many parts will want to make coordinating with > hundreds of people incrementally, while people connected to few parts are > far better served by communicating only with the people they need to > (communication famously scales badly). > I would assume we will eventually want to open up our github repository to pull requests. When that happens, if you use a separate bugtracker then clangd issues will be split across the two: pull requests will be sent to the monorepo because (as far as I'm aware) a pull request for a repo can only be sent to that repo's issue tracker, but your "regular" issues will be elsewhere. And even that is a rosier picture than I expect you'll actually experience: people will file issues for clangd on the issue tracker attached to the clangd repository, simply because that's how the github workflow works in general. So if you keep a separate issue tracker, I think you will de facto end up with two issue trackers for clangd, and will spend some amount of ongoing effort managing that. So, I think you might be underestimating the costs here if you've not taken that into account already. That said, moving issues between repos is apparently feasible, so it seems like we could use clangd as an experiment to find out how major or minor these concerns actually are. Getting back to the proposal we are discussing. Do you have any specific >> feedback >> for improvements that might help make it align better with the kind of >> experience >> the clangd users and developers are looking for? >> > Sorry if it seemed I was trying to derail: I think sharding into multiple > repos *is* a specific improvement that should be considered, though there > are arguments against it. > If "the proposal we are discussing" doesn't admit changes, well, I'm +1 on > its current form too :-) > > Other suggestions: > > Issue templates: I think you need at least one for each component. > Users will be less familiar with the bug tracker conventions than > developers are, especially given that this one is unusual in covering > multiple products. Forcing a choice between the "component" tags as well as > guiding them to include relevant info leaves less of an unstructured mess > to triage. This helps mitigate the fact that the UI won't separate > component tags like "lld" from others like "crash-on-invalid". > (Fortunately these don't need to be maintained centrally: editing > templates just needs commit access) > > Tag namespace: I can see this becoming a mess quickly, it's hard to choose > the right tags if there are too many, so there can be a bit of a > tragedy-of-the-commons. (Seeding it with lots of "component" tags doesn't > help). Maybe these should be centrally designed. > I wonder if the "projects" feature can be used for components? It's not > really the intended purpose (looks like they're supposed to be time-limited > like sprints) but maybe they can work as a second tag namespace, and the > name fits... > > Releases: my most active times on bugzilla are when dealing with release > blockers in the run-up to a release. As GH issues lacks blocking bugs, I'm > a bit curious what the workflow is for this (and probably worth considering > before the release is upon us). I guess "projects" might be a good fit. > > Preserving bug numbers: seems worth it to me, but I have no special > insight. > > Again, thanks a lot for working on this, I think it'll be a substantial > improvement to land it in any form (however much I end up using it myself). > > >> >> - Tom >> >> >> >> >> >> _______________________________________________ > 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: From openmp-dev at lists.llvm.org Fri Apr 24 18:42:43 2020 From: openmp-dev at lists.llvm.org (Michael Kruse via Openmp-dev) Date: Fri, 24 Apr 2020 20:42:43 -0500 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <7754a710-d773-28a7-69cd-e4246a5a7a8f@redhat.com> Message-ID: Am Fr., 24. Apr. 2020 um 16:13 Uhr schrieb Sam McCall via cfe-dev : > On Fri, Apr 24, 2020 at 9:03 PM Tom Stellard wrote: >> On 04/24/2020 03:24 AM, Sam McCall wrote: >> > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! >> > >> > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). >> > As such I don't think we should migrate clangd to a using the monorepo bugtracker. Email subscription to a label is better than nothing, but worse than a separate repo. >> > Removing the clangd label from the monorepo bugtracker seems like the simplest thing, though I'm happy to work on auto-moving bugs if that's better. >> > >> > (I'd suggest considering the same for other subprojects, though I know that's not a popular opinion here) >> >> I think it's important for everything in the monorepo to use the same bug tracker. >> >> There are advantages to having code in the monorepo (e.g. free >> updates for API changes, a more consistent build experience, etc.). >> But there are also costs, as you have pointed out, like having to use >> a less than ideal bug tracker. It's really up to sub-projects >> to make the decision about whether these benefits are worth the costs. >> The flang developers have just gone through this process and have >> had to make some sacrifices to get the code in, but ultimately felt the >> sacrifices were worth it. >> >> I think it hurts the ability of developers and users to collaborate effectively, >> if the infrastructure for the project is spread across too many different places. >> And good collaboration is key for a project of this size with some many tightly >> connected components. > > (sorry, I should probably not tilt at this windmill. More on-topic stuff below, I promise!) > Right, and I think having a single-project view of the LLVM organization is a mistake: it's a graph of projects, some are highly connected and some are not. > The monorepo has a strong technical reason: the graph is connected and accepting a CI boundary anywhere is expensive in the absence of stable APIs. > But this is much less true for bug tracking systems: the cost to crossing boundaries is smaller. > For clangd, the benefit of sharing a tracker with clang AST+Sema is less than the cost of sharing a tracker with clang codegen, LLVM proper, LLD, flang, MLIR, ... (and the opposite is true for source control/CI). > Anyway, this is going to depend on what part(s) of the project graph you touch: people connected to many parts will want to make coordinating with hundreds of people incrementally, while people connected to few parts are far better served by communicating only with the people they need to (communication famously scales badly). I think there is another aspect important to mention. Users not familiar with the LLVM developers tooling will see an official GitHub project that allows submitting bugs. It is non-obvious that there is another GitHub project just for bug tracking, especially if there are multiple of those for different subprojects and even worse if the main repository itself has an active issue tracker. As with the current GitHub projects, we already had ~200 issues filed even though we did not even intent to use GitHub for this. Michael From openmp-dev at lists.llvm.org Mon Apr 27 09:07:30 2020 From: openmp-dev at lists.llvm.org (Philip Reames via Openmp-dev) Date: Mon, 27 Apr 2020 09:07:30 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <7754a710-d773-28a7-69cd-e4246a5a7a8f@redhat.com> Message-ID: <88edf05c-9f24-7ba3-65b9-7f059c12ecb3@philipreames.com> On 4/25/20 10:02 PM, Mehdi AMINI via cfe-dev wrote: > > > On Fri, Apr 24, 2020 at 12:04 PM Tom Stellard via llvm-dev > > wrote: > > On 04/24/2020 03:24 AM, Sam McCall wrote: > > clangd's experience using github issues to track bugs (in a > separate repo) has been very positive, and I'm glad you're pushing > on this! > > > > Part of this has been that our issue tracker has been scoped to > our subproject only, which is a scope that the tool works well for > (on the user and developer side). > > As such I don't think we should migrate clangd to a using the > monorepo bugtracker. Email subscription to a label is better than > nothing, but worse than a separate repo. > > Removing the clangd label from the monorepo bugtracker seems > like the simplest thing, though I'm happy to work on auto-moving > bugs if that's better. > > > > (I'd suggest considering the same for other subprojects, though > I know that's not a popular opinion here) > > I think it's important for everything in the monorepo to use the > same bug tracker. > > There are advantages to having code in the monorepo (e.g. free > updates for API changes, a more consistent build experience, etc.). > But there are also costs, as you have pointed out, like having to use > a less than ideal bug tracker.  It's really up to sub-projects > to make the decision about whether these benefits are worth the costs. > The flang developers have just gone through this process and have > had to make some sacrifices to get the code in, but ultimately > felt the > sacrifices were worth it. > > > I think it hurts the ability of developers and users to > collaborate effectively, > if the infrastructure for the project is spread across too many > different places. > And good collaboration is key for a project of this size with some > many tightly > connected components. > > > +1: seems like clangd here is trying a "in-between" approach in being > halfway into a LLVM project. It was something that was strongly pushed > back against multiple times during the discussions on Flang > integration, it isn't clear to me why we'd get into a different > approach with clangd. I am really in favor of keeping a cohesion in > the project and not having a "graph of somehow disconnected projects". > There might be sub-optimality sometimes, but we should address them > for everyone instead of one-off improvements that may benefit one > subproject on the short term but I suspect hurt the project on the > long term. +1.  Agreed w/Mehdi. > > -- > Mehdi > > > Getting back to the proposal we are discussing.  Do you have any > specific feedback > for improvements that might help make it align better with the > kind of experience > the clangd users and developers are looking for? > > - Tom > > > > > > _______________________________________________ > 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: From openmp-dev at lists.llvm.org Tue Apr 28 04:04:08 2020 From: openmp-dev at lists.llvm.org (Jon Chesterfield via Openmp-dev) Date: Tue, 28 Apr 2020 12:04:08 +0100 Subject: [Openmp-dev] Support for static libomptarget Message-ID: OpenMP links a libomptarget.so into the host executable which goes looking for offloading toolchains to dlopen. This is very flexible, but comes at a price: - PLT call overhead + inlining barrier - Startup overhead looking for the toolchain - Failing to dlopen will run the host fallback, which is not necessarily what one wants for debugging For device toolchains that are available as static libraries, and for deployment of the toolchain to a system with known, fixed hardware (e.g. some hpc clusters), I'd like to be able to statically link everything. Faster and fewer failure modes. Particularly fun for amdgcn, because we'll be able to statically link the userspace graphics driver into the host executable as well. No shared libraries necessary. Involves a change to libomptarget (that I haven't written yet) to fill in function pointers without dlopen, and some cmake logic/controls to specify which toolchains are dynamic/static/unavailable. Plus building libomptarget.a if that isn't yet implemented. Are patches for this nominally welcome? Thanks Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Wed Apr 29 08:24:48 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Wed, 29 Apr 2020 08:24:48 -0700 Subject: [Openmp-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> Message-ID: <92a3b37b-1f77-9213-ca37-0fe2a4567ec8@redhat.com> Hi, Thanks to everyone who provided feedback. I would like to propose a more detailed plan based on the everyone's comments. It seems like there was a strong preference to maintain the bug ID numbers, so this proposal tries to address that. TLDR; This proposes to maintain bug ID numbers by overwriting existing GitHub issues instead of creating new ones. e.g. github.com/llvm/llvm-project/issues/1 will be overwritten with data from llvm.org/PR1. There will be some bugs that end up having their data copied into pull requests, which may be strange, but the data will be preserved and the IDs will be preserved and this would only happen to very old bugs. Proposal: Detailed steps for doing the migration: * Weeks or days before the migration: 1. Create a new GitHub repository called llvm-bug-archive and import bug data from bugzilla. This step should not be under any kind of time pressure, so that the conversion process can be debugged and refined. 2. Install label notification system using GitHub actions and enable web hook to send emails to llvm-bugs list. * Day before the migration: 3. Make bugzilla readonly. 4. Import any new bugs created since the last import. There may be commit access disruption during the migration, so completing these steps the day before will limit the amount of down time. 5. Temporarily re-enable issues in the llvm-project repo and copy existing issues to the llvm-bug-archive repo so they get higher IDs numbers than any existing PR. Disable issues when done. Note that we will copy issues instead of moving them, which means the original issue will remain in tact. This will allow us to retain the bug IDs for future use and not 'lose' a bug ID. * Day of migration: 6. Lockdown the repo as much as possible to prevent people from creating issues or pull requests. Temporarily making the repo private may be one way to achieve this. Other suggestions welcome. 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo into the llvm-project repo. Issues from the llvm-bug-archive repo that have the same ID number as existing issues in the llvm-project repo will be manually copied from the former to the later. This will allow us to preserve the PR numbers from bugzilla. Here is an example for how this would work: - Delete comments and description from llvm-project issue #1. - Copy comments and description from llvm-bug-archive issue #1 into llvm-project issue #1. Since GitHub issue and pull requests share the same numbering sequence, any PR# from bugzilla that maps to a pull request in the llvm-project repo will need to have it's comments copied into a pull request. These issues will look slightly strange since there will be random commits attached to the issue. However, all data will be preserved and more importantly the bug ID will be preserved. The issues URL can be used to access pull requests e.g. pull request #84 is accessible via github.com/llvm/llvm-project/issues/84 so even with bugzilla data stored in pull requests, we will still be able to do a simple redirect from llvm.org/PR### to github.com/llvm/llvm-project/issues/### 8. Once all the overlapping Issue IDs have been copied. Move the rest of the issues from the llvm-bug-archive repo to the llvm-project repo. This should be faster than doing the copies since we do not need to overwrite existing issues and can just move the issues from one repo to the other. The end result of this is that we have all the old bugs from bugzilla present as issues in the llvm-project repository with all of their ID numbers preserved. * Other action items: - We need volunteers to help create bug templates to simplify the process of submitting bugs. If you are interested in helping with this, let me know. - Continue to iterate on the set of issue labels. This should not block the migration since labels can be changed at any time, but there were some suggested improvements that should be discussed. Please reply to this proposal with your questions, comments, praise, or concerns. Thanks, Tom [1] https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev 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. > > > 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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > From openmp-dev at lists.llvm.org Wed Apr 29 09:23:26 2020 From: openmp-dev at lists.llvm.org (Finkel, Hal J. via Openmp-dev) Date: Wed, 29 Apr 2020 16:23:26 +0000 Subject: [Openmp-dev] Support for static libomptarget In-Reply-To: References: Message-ID: Hi, Jon, I think that it's a good idea to enable this use case. It might not be the default, but some CMake flags to enable a static offloading library would see some use. -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Openmp-dev on behalf of Jon Chesterfield via Openmp-dev Sent: Tuesday, April 28, 2020 6:04 AM To: Doerfert, Johannes via Openmp-dev Subject: [Openmp-dev] Support for static libomptarget OpenMP links a libomptarget.so into the host executable which goes looking for offloading toolchains to dlopen. This is very flexible, but comes at a price: - PLT call overhead + inlining barrier - Startup overhead looking for the toolchain - Failing to dlopen will run the host fallback, which is not necessarily what one wants for debugging For device toolchains that are available as static libraries, and for deployment of the toolchain to a system with known, fixed hardware (e.g. some hpc clusters), I'd like to be able to statically link everything. Faster and fewer failure modes. Particularly fun for amdgcn, because we'll be able to statically link the userspace graphics driver into the host executable as well. No shared libraries necessary. Involves a change to libomptarget (that I haven't written yet) to fill in function pointers without dlopen, and some cmake logic/controls to specify which toolchains are dynamic/static/unavailable. Plus building libomptarget.a if that isn't yet implemented. Are patches for this nominally welcome? Thanks Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From openmp-dev at lists.llvm.org Wed Apr 29 13:19:57 2020 From: openmp-dev at lists.llvm.org (David Blaikie via Openmp-dev) Date: Wed, 29 Apr 2020 13:19:57 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: <92a3b37b-1f77-9213-ca37-0fe2a4567ec8@redhat.com> References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <92a3b37b-1f77-9213-ca37-0fe2a4567ec8@redhat.com> Message-ID: Generally sounds pretty good to me - only variation on the theme (& certainly imho dealer's choice at this point - if you/whoever ends up doing this doesn't like the sound of it, they shouldn't feel they have to do it this way) - maybe creating blank issues up to the current bugzilla PR number (& maybe some padding) in a single/quick-ish (no idea how quickly those can be created) window might help reduce the need for race conditions/shutting down bug reporting, etc On Wed, Apr 29, 2020 at 8:25 AM Tom Stellard via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi, > > Thanks to everyone who provided feedback. I would like to propose a > more detailed plan based on the everyone's comments. It seems like there > was a strong > preference to maintain the bug ID numbers, so this proposal tries to > address that. > > TLDR; This proposes to maintain bug ID numbers by overwriting existing > GitHub issues > instead of creating new ones. e.g. github.com/llvm/llvm-project/issues/1 > will > be overwritten with data from llvm.org/PR1. There will be some bugs that > end up having their data copied into pull requests, which may be strange, > but the data will be preserved and the IDs will be preserved and this would > only happen to very old bugs. > > Proposal: > > Detailed steps for doing the migration: > > > * Weeks or days before the migration: > > 1. Create a new GitHub repository called llvm-bug-archive and import bug > data from bugzilla. > > This step should not be under any kind of time pressure, so that the > conversion > process can be debugged and refined. > > 2. Install label notification system using GitHub actions and enable web > hook > to send emails to llvm-bugs list. > > * Day before the migration: > > 3. Make bugzilla readonly. > > 4. Import any new bugs created since the last import. > > There may be commit access disruption during the migration, so > completing these steps the day before will limit the amount of down time. > > 5. Temporarily re-enable issues in the llvm-project repo and copy existing > issues > to the llvm-bug-archive repo so they get higher IDs numbers than any > existing PR. Disable issues when done. > > Note that we will copy issues instead of moving them, which means the > original > issue will remain in tact. This will allow us to retain the bug IDs > for future use and not 'lose' a bug ID. > > * Day of migration: > > 6. Lockdown the repo as much as possible to prevent people from creating > issues or pull requests. > > Temporarily making the repo private may be one way to achieve this. Other > suggestions welcome. > > 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo > into the llvm-project repo. > > Issues from the llvm-bug-archive repo that have the same ID number as > existing issues in the llvm-project repo will be manually copied from > the former to the later. This will allow us to preserve the PR numbers > from bugzilla. Here is an example for how this would work: > > - Delete comments and description from llvm-project issue #1. > - Copy comments and description from llvm-bug-archive issue #1 into > llvm-project issue #1. > > Since GitHub issue and pull requests share the same numbering sequence, any > PR# from bugzilla that maps to a pull request in the llvm-project repo will > need to have it's comments copied into a pull request. These issues will > look slightly > strange since there will be random commits attached to the issue. However, > all data will be preserved and more importantly the bug ID will be > preserved. > > The issues URL can be used to access pull requests e.g. > pull request #84 is accessible via github.com/llvm/llvm-project/issues/84 > so even with bugzilla data stored in pull requests, we will still be able > to do a simple redirect > from llvm.org/PR### to > github.com/llvm/llvm-project/issues/### > > > > 8. Once all the overlapping Issue IDs have been copied. Move the rest of > the issues > from the llvm-bug-archive repo to the llvm-project repo. > > This should be faster than doing the copies since we do not need to > overwrite existing > issues and can just move the issues from one repo to the other. > > The end result of this is that we have all the old bugs from bugzilla > present as issues > in the llvm-project repository with all of their ID numbers preserved. > > > * Other action items: > > - We need volunteers to help create bug templates to simplify the process > of submitting > bugs. If you are interested in helping with this, let me know. > > - Continue to iterate on the set of issue labels. This should not block > the migration since > labels can be changed at any time, but there were some suggested > improvements that should > be discussed. > > > Please reply to this proposal with your questions, comments, praise, or > concerns. > > Thanks, > Tom > > > [1] > https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates > > > > > On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev 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. > > > > > > 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 > > 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: From openmp-dev at lists.llvm.org Thu Apr 30 09:48:31 2020 From: openmp-dev at lists.llvm.org (Tom Stellard via Openmp-dev) Date: Thu, 30 Apr 2020 09:48:31 -0700 Subject: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED] In-Reply-To: References: <199284c6-8a38-7ae4-8c13-c9640327c3f3@redhat.com> <92a3b37b-1f77-9213-ca37-0fe2a4567ec8@redhat.com> Message-ID: On 04/29/2020 01:19 PM, David Blaikie wrote: > Generally sounds pretty good to me - only variation on the theme (& certainly imho dealer's choice at this point - if you/whoever ends up doing this doesn't like the sound of it, they shouldn't feel they have to do it this way) - maybe creating blank issues up to the current bugzilla PR number (& maybe some padding) in a single/quick-ish (no idea how quickly those can be created) window might help reduce the need for race conditions/shutting down bug reporting, etc > I think this is a really good suggestion. It would take a lot of pressure off the migration process. The only potential downside is that copying into blank issues might be slower than just moving the issues. I have not tested this, so I don't know yet, but even if copying is slower it doesn't really matter that much if there is nothing (e.g. re-enabling repo access) that is waiting on the process to complete. -Tom > On Wed, Apr 29, 2020 at 8:25 AM Tom Stellard via cfe-dev > wrote: > > Hi, > > Thanks to everyone who provided feedback. I would like to propose a > more detailed plan based on the everyone's comments. It seems like there was a strong > preference to maintain the bug ID numbers, so this proposal tries to address that. > > TLDR; This proposes to maintain bug ID numbers by overwriting existing GitHub issues > instead of creating new ones. e.g. github.com/llvm/llvm-project/issues/1 will > be overwritten with data from llvm.org/PR1 . There will be some bugs that > end up having their data copied into pull requests, which may be strange, > but the data will be preserved and the IDs will be preserved and this would > only happen to very old bugs. > > Proposal: > > Detailed steps for doing the migration: > > > * Weeks or days before the migration: > > 1. Create a new GitHub repository called llvm-bug-archive and import bug > data from bugzilla. > > This step should not be under any kind of time pressure, so that the conversion > process can be debugged and refined. > > 2. Install label notification system using GitHub actions and enable web hook > to send emails to llvm-bugs list. > > * Day before the migration: > > 3. Make bugzilla readonly. > > 4. Import any new bugs created since the last import. > > There may be commit access disruption during the migration, so > completing these steps the day before will limit the amount of down time. > > 5. Temporarily re-enable issues in the llvm-project repo and copy existing issues > to the llvm-bug-archive repo so they get higher IDs numbers than any > existing PR. Disable issues when done. > > Note that we will copy issues instead of moving them, which means the original > issue will remain in tact. This will allow us to retain the bug IDs > for future use and not 'lose' a bug ID. > > * Day of migration: > > 6. Lockdown the repo as much as possible to prevent people from creating > issues or pull requests. > > Temporarily making the repo private may be one way to achieve this. Other > suggestions welcome. > > 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo > into the llvm-project repo. > > Issues from the llvm-bug-archive repo that have the same ID number as > existing issues in the llvm-project repo will be manually copied from > the former to the later. This will allow us to preserve the PR numbers > from bugzilla. Here is an example for how this would work: > > - Delete comments and description from llvm-project issue #1. > - Copy comments and description from llvm-bug-archive issue #1 into > llvm-project issue #1. > > Since GitHub issue and pull requests share the same numbering sequence, any > PR# from bugzilla that maps to a pull request in the llvm-project repo will > need to have it's comments copied into a pull request. These issues will look slightly > strange since there will be random commits attached to the issue. However, > all data will be preserved and more importantly the bug ID will be preserved. > > The issues URL can be used to access pull requests e.g. > pull request #84 is accessible via github.com/llvm/llvm-project/issues/84 > so even with bugzilla data stored in pull requests, we will still be able to do a simple redirect > from llvm.org/PR### to github.com/llvm/llvm-project/issues/### > > > 8. Once all the overlapping Issue IDs have been copied. Move the rest of the issues > from the llvm-bug-archive repo to the llvm-project repo. > > This should be faster than doing the copies since we do not need to overwrite existing > issues and can just move the issues from one repo to the other. > > The end result of this is that we have all the old bugs from bugzilla present as issues > in the llvm-project repository with all of their ID numbers preserved. > > > * Other action items: > > - We need volunteers to help create bug templates to simplify the process of submitting > bugs. If you are interested in helping with this, let me know. > > - Continue to iterate on the set of issue labels. This should not block the migration since > labels can be changed at any time, but there were some suggested improvements that should > be discussed. > > > Please reply to this proposal with your questions, comments, praise, or concerns. > > Thanks, > Tom > > > [1] https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates > > > > > On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev 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. > > > > > > 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 > > 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 >