[cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Philip Reames via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 22 09:45:28 PDT 2020
On 4/21/20 6:50 PM, Richard Smith wrote:
> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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>
> <mailto: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?
>
>
> These numbers appear all over our codebase. PR[0-9] appears 3592 times
> in Clang testcases, plus 45 times in Clang source code and 119 times
> more as the file names of Clang testcases. If we add inconvenience to
> looking up all of those, that makes maintenance harder each time
> someone wants to look one of those up. (That's probably a ~weekly
> occurrence for me.)
For this use case, a simple script and bulk change to update references
in source repo means the numbering can change arbitrarily. ~4k small
mechanical changes is just not that much to review for a one time update
assuming you trust the number remapping script and are just looking for
overly aggressive regex matches.
(I don't have any quick fixes for your other mentioned cases.)
>
> Also, bug numbers appear in other bugs. I would assume we're not going
> to be able to reliably figure out which numbers appearing in a bug are
> bug numbers during the import process, so those numbers will persist
> into the github issues world.
>
> (In addition, I'm sure multiple groups have their own tracking
> systems, web pages, documentation, etc. that contain references to
> LLVM PR numbers. But maybe we shouldn't worry too much about that.)
>
> Could you help give some example use cases that require having
> a non-intersecting set of bug numbers for bugzilla bugs and github
> issues?
>
>
> It makes conversing about bug numbers more difficult if you need to
> clarify which system you're talking about. As a minor example, we'd
> have to avoid saying "PR" for the new system in order to avoid
> confusion, and get used to some new terminology, and probably not use
> "bug 1234" to describe either system, because that would be ambiguous.
> None of these individual factors seems like a huge disruption, but
> they all seem like inconvenience we should prefer to avoid if possible.
>
> -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>
> <mailto: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>
> <mailto: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>
> <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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200422/d26d14e9/attachment-0001.html>
More information about the cfe-dev
mailing list