Philip Reames via llvm-dev
2021-Dec-02 16:05 UTC
[llvm-dev] [cfe-dev] Status of Bugzilla Migration
This thought had occurred to me as well. Using a separate repo for bug tracking seems reasonable as an intermediate step. Unless there's a complexity here I'm missing, I'd probably vote for that in favor of going all the way back to bugzilla. Philip p.s. Anton, thank you for the update and all the work that has gone into this. On 12/2/21 12:18 AM, MyDeveloper Day via llvm-dev wrote:> What bad stuff happens if you just open up > https://github.com/llvm/llvm-bugzilla-archive/issues > <https://github.com/llvm/llvm-bugzilla-archive/issues> (even if you > then make another historical archive later) to use as the bug tracker > until you and github have ironed out all the migration from one > project to another project issues? rather than going all the way back > to bugzillia which is then going to impose some other multi day > migration at a later point. > > In my mind I've already divorced from bugzilla, I'm ready to move on > with my life with github! > > MyDeveloperDay > > On Thu, Dec 2, 2021 at 7:36 AM Anton Korobeynikov via cfe-dev > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > Dear All, > > Some of you who are checking the migration notes > (https://bit.ly/3HVjr7a <https://bit.ly/3HVjr7a>) might already > have noticed that we're stuck > again. Let me provide more information about what is going on now and > what the plans are. > > As a reminder, previously we imported all issues in the archive repo > and essentially the very last step remained: migration to the live > llvm-project repo. This step is crucial and one-way, once started we > cannot undo the steps we'd made. We also have to rely on GitHub here > as we cannot do it via rate-limited API calls > > During the final checks two issues were revealed: > - Notifications are still sent in some cases > - Migration sets the last modification date of the closed issues (it > looks like it was implemented like "re-open issue, transfer and close > again"). As a result, all closed issues essentially got sorted > chronologically before the real open ones. > > These issues were fixed at GitHub side and we proceeded with > re-checking everything. It turned out that another issue appeared: the > labels were silently lost and the migrated issues were completely > labelless, despite being annotated by 140+ labels we had originally. > For now this is a show-stopper issue. The issue was reported and > acknowledged by GitHub, however, not ETA was provided. > > Our current options are: > 1. Abandon the migration > 2. Wait until the issue is resolved on GitHub side > 3. Try to find alternative solutions to workaround GitHub issue > > 2. is essentially not an option. I am proposing to abandon the > migration and unlock the bugzilla if the solution will not be found by > the end of this week. > > The only alternative I'm seeing is to apply the labels post-migration. > There are important downsides: > - This has to be done via GitHub API and we're rate limited to ~5000 > requests per hour, so this means that the labelling will take ~20 > hours. I was told that there is no way for us to have the API rate > limit increased. > - This might trigger notifications. My quick check via web ui does > not, but I cannot be 100% with anything here > - (the most important) This will screw the "last modified" timestamp > as label setting is an event that is recorded in the issue. There is > no way to set some "old" timestamp, it is assigned by GitHub > automatically. > > For now I'm testing the script for 3. and waiting for any news > from GitHub. > > I will keep you updated. > > -- > With best regards, Anton Korobeynikov > On behalf of LLVM Foundation > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > <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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211202/cdfcb51d/attachment.html>
If there are new issues created directly in llvm-bugzilla-archive, and they have cross-references to other (new or old) issues, we’d want to make sure they get fixed up along with the originally-from-bugzilla references. (Recall that all issues will be renumbered when they move to llvm-project.) It would be mildly annoying to have the bug repo move twice instead of once, but if the reference re-writing works correctly then I don’t have any real objection. --paulr From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Philip Reames via cfe-dev Sent: Thursday, December 2, 2021 11:06 AM To: MyDeveloper Day <mydeveloperday at gmail.com>; Anton Korobeynikov <anton at korobeynikov.info> Cc: llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>; Flang Development List <flang-dev at lists.llvm.org>; openmp-dev (openmp-dev at lists.llvm.org) <openmp-dev at lists.llvm.org>; polly-dev <polly-dev at googlegroups.com> Subject: Re: [cfe-dev] [llvm-dev] Status of Bugzilla Migration This thought had occurred to me as well. Using a separate repo for bug tracking seems reasonable as an intermediate step. Unless there's a complexity here I'm missing, I'd probably vote for that in favor of going all the way back to bugzilla. Philip p.s. Anton, thank you for the update and all the work that has gone into this. On 12/2/21 12:18 AM, MyDeveloper Day via llvm-dev wrote: What bad stuff happens if you just open up https://github.com/llvm/llvm-bugzilla-archive/issues<https://urldefense.com/v3/__https:/github.com/llvm/llvm-bugzilla-archive/issues__;!!JmoZiZGBv3RvKRSx!vPnNEFBugladxykTZQg0nWDyHh1W0XuGWqLd0Lr8BnkWZqftW5lMz5Qve1zfDp-GwA$> (even if you then make another historical archive later) to use as the bug tracker until you and github have ironed out all the migration from one project to another project issues? rather than going all the way back to bugzillia which is then going to impose some other multi day migration at a later point. In my mind I've already divorced from bugzilla, I'm ready to move on with my life with github! MyDeveloperDay On Thu, Dec 2, 2021 at 7:36 AM Anton Korobeynikov via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote: Dear All, Some of you who are checking the migration notes (https://bit.ly/3HVjr7a<https://urldefense.com/v3/__https:/bit.ly/3HVjr7a__;!!JmoZiZGBv3RvKRSx!vPnNEFBugladxykTZQg0nWDyHh1W0XuGWqLd0Lr8BnkWZqftW5lMz5Qve1yYHVBnBA$>) might already have noticed that we're stuck again. Let me provide more information about what is going on now and what the plans are. As a reminder, previously we imported all issues in the archive repo and essentially the very last step remained: migration to the live llvm-project repo. This step is crucial and one-way, once started we cannot undo the steps we'd made. We also have to rely on GitHub here as we cannot do it via rate-limited API calls During the final checks two issues were revealed: - Notifications are still sent in some cases - Migration sets the last modification date of the closed issues (it looks like it was implemented like "re-open issue, transfer and close again"). As a result, all closed issues essentially got sorted chronologically before the real open ones. These issues were fixed at GitHub side and we proceeded with re-checking everything. It turned out that another issue appeared: the labels were silently lost and the migrated issues were completely labelless, despite being annotated by 140+ labels we had originally. For now this is a show-stopper issue. The issue was reported and acknowledged by GitHub, however, not ETA was provided. Our current options are: 1. Abandon the migration 2. Wait until the issue is resolved on GitHub side 3. Try to find alternative solutions to workaround GitHub issue 2. is essentially not an option. I am proposing to abandon the migration and unlock the bugzilla if the solution will not be found by the end of this week. The only alternative I'm seeing is to apply the labels post-migration. There are important downsides: - This has to be done via GitHub API and we're rate limited to ~5000 requests per hour, so this means that the labelling will take ~20 hours. I was told that there is no way for us to have the API rate limit increased. - This might trigger notifications. My quick check via web ui does not, but I cannot be 100% with anything here - (the most important) This will screw the "last modified" timestamp as label setting is an event that is recorded in the issue. There is no way to set some "old" timestamp, it is assigned by GitHub automatically. For now I'm testing the script for 3. and waiting for any news from GitHub. I will keep you updated. -- With best regards, Anton Korobeynikov On behalf of LLVM Foundation _______________________________________________ cfe-dev mailing list cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!vPnNEFBugladxykTZQg0nWDyHh1W0XuGWqLd0Lr8BnkWZqftW5lMz5Qve1wd7ql3zw$> _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!vPnNEFBugladxykTZQg0nWDyHh1W0XuGWqLd0Lr8BnkWZqftW5lMz5Qve1zH6-oekA$> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211202/749e9f6b/attachment.html>