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 <cfe-...@lists.llvm.org> 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 > <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> >>> >>> 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 > > _______________________________________________ > cfe-dev mailing list > cfe-...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
