similar to: RFC: Switching from Bugzilla to Github Issues [UPDATED]

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

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

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 <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> +1 to James's take >> >> I'd prefer simplicity of implementation over perfection here.

On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: > > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > > +1 to James's take > > > > I'd

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.)

> 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

> 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

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,

Dear all, Over the last few weeks with the help of GH folks I've been exploring the options of Bugzilla migration. I believe finally we came to the viable solution which is detailed below. It turned out that GitHub has an internal project rehydration tool that could be used to populate the empty repo contents from the simple serialized format. There is a big advantage of this approach as

Well, it's not really critical for us _now_, because we have not switched to github issues. And I can't really see any possibility of that happening in the short-term, either. Even once we do decide we want to move that way -- which we haven't yet even done -- it'll be a long road to making it happen, and I suspect there's many more critical missing features that we'll

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

Hi LLVM community, As discussed earlier, we in the clangd land feel that buganizer does not address the clangd's needs as a bug-tracking system. In our previous attempt to raise this on llvm-dev [1] we shared our idea to put the clangd issue tracker on GitHub. The participants raised multiple concerns, including the migration costs, whether GitHub is the right choice as an issue tracker,

My expectation was that they would continue to be fed from the updates to the svn repo. But again, I don't recall where I got that impression from. It may have been a bad assumption on my part. Tom. From: Anton Korobeynikov <anton at korobeynikov.info> Sent: Tuesday, February 25, 2020 12:36 PM To: Tom Honermann <thonerma at synopsys.com> Cc: llvm-dev at lists.llvm.org; Michael

Hi all- I was wondering if anyone knew what the status/schedule of the SVN to git/github transition was? I thought I saw that at the November meeting it was agreed upon, but I'm not sure I saw any progress since? Thanks, Erich

On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: > I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > > While I haven't performed this particular trick on Github, based on my experience

On 03/16/2020 07:53 AM, Aaron Ballman wrote: > On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> On 02/10/2020 07:40 PM, Tom Stellard wrote: >>> On 01/30/2020 12:47 PM, David Major wrote: >>>> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place?

On 02/10/2020 07:40 PM, Tom Stellard wrote: > On 01/30/2020 12:47 PM, David Major wrote: >> Would it make sense to wait until 10.0.0 is released, in order to keep all the blockers in one place? >> > > Yes, I think this makes sense, let's postpone until then. > Hi, 10.0.0-rc4 was just released, and I think we are at the point in the release cycle where it is safe to

We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github functionality was also discussed -- but that should be for other email threads. Most of the ideas here were from other people. I *believe* this proposal represents the overall

Hi, We are still on track to retire SVN and complete the transition to GitHub by Oct 21, 2019 (This year's US Dev Meeting). Even though this 3+ months away, it is very important that you begin to migrate your workflows to GitHub as soon as possible. For developers, this means using the git-llvm script to commit changes and for CI systems or other read-only use cases can begin fetching code

On 03/16/2020 10:13 AM, Florian Hahn wrote: > Hi, > >> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I've also implemented a notification system using GitHub actions that will make >> it possible to subscribe to individual issue tags, so we would enable this on Monday