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

Philip Reames via lldb-dev lldb-dev at lists.llvm.org
Wed Apr 22 14:52:29 PDT 2020


On 4/22/20 2:35 PM, Richard Smith wrote:
> On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     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.
>
> It's not quite as straightforward as you're suggesting: such a simple 
> script would break a bunch of our CodeGen tests that match mangled 
> names, if the length of any bug identifier changes. A grep for 
> '_Z.*PR[0-9]' indicates that there are at least 254 of those that 
> might need manual updating if we took this path.
We have an auto-updater for most llc scripts, but point taken.  My main 
point was this was one time, not that the one time was trivial.
>
>     (I don't have any quick fixes for your other mentioned cases.)
>
> Another case I didn't think of before, but that seems very important: 
> bug numbers appear in commit messages, and are primary context in 
> understanding what the commit is doing and why. [We *could* go on a 
> bulk history editing spree to fix those commit messages up (git 
> filter-branch actually makes this fairly easy) -- but that too would 
> create a little churn as everyone would needs to rebase all their work 
> in progress on the rewritten master, and honestly, that sounds a lot 
> scarier than any of the other things we've considered in this thread :)]
Agreed, history rewrite as a solution here should be rejected out of 
hand.  :)
>
>>     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
>>
>     _______________________________________________
>     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200422/020635a5/attachment-0001.html>


More information about the lldb-dev mailing list