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 <BZPRODUCT>/<BZCOMPONENT>. 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 < cfe-...@lists.llvm.org> 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 < > cfe-...@lists.llvm.org> 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 < > cfe-...@lists.llvm.org> 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 < >> cfe-...@lists.llvm.org <mailto:cfe-...@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? 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### >> <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> be the url only >> for legacy bugzilla issue numbers -- and have it use a file listing the >> mappings of bugzilla id -> github id to generate the redirects. (GCC just >> did this recently for svn revision number redirections, >> https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html). >> >>> >> >>> Then we could introduce a new naming scheme for github issue >> shortlinks. >> >>> >> >>> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev < >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote: >> >>> >> >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < >> llvm-...@lists.llvm.org <mailto:llvm-...@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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >>> >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> >> cfe-dev mailing list >> >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >> >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-...@lists.llvm.org >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-...@lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
