[lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
James Y Knight via lldb-dev
lldb-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/lldb-dev/attachments/20200422/6586eac6/attachment-0001.html>
More information about the lldb-dev
mailing list