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

Philip Reames via llvm-dev llvm-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/llvm-dev/attachments/20200422/d26d14e9/attachment-0001.html>


More information about the llvm-dev mailing list