[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Konrad Kleine via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 22 04:20:31 PDT 2020
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-dev at 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-dev at 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-dev at 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-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.
>> >>
>> >> 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-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> >>>
>> >>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at 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-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >> _______________________________________________
>> >> 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
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/ffd7e1e3/attachment.html>
More information about the llvm-dev
mailing list