[cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Wed Apr 22 05:13:55 PDT 2020


GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and
also supports "GH-NNN". We'll want to switch to one of those schemes, so
that automatic linking works properly. So, in that case, PR1234 == legacy
issue, #1234 or GH-1234 == new issue.

(See
https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls
)

On Tue, Apr 21, 2020, 10:43 PM 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200422/6586eac6/attachment-0001.html>


More information about the cfe-dev mailing list