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 <mailto: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> > >> <mailto: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 <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 > >>> <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> > >>> <mailto: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> > >>> <mailto: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 > >>> <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 > >>> <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> <http://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> > >>> <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > >>> <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >>> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > >>> <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >> _______________________________________________ > >> cfe-dev mailing list > >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > >> <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> <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 > > <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 > <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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
