<div dir="ltr"><div dir="ltr">On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>On 4/21/20 6:50 PM, Richard Smith
      wrote:<br></p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">On Tue, 21 Apr 2020 at 17:00, Tom Stellard via
          llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
          wrote:<br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/21/2020 03:36 PM,
            Richard Smith via llvm-dev wrote:<br>
            > On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
            <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>>
            wrote:<br>
            > <br>
            >     +1 to James's take<br>
            > <br>
            >     I'd prefer simplicity of implementation over
            perfection here.<br>
            > <br>
            > 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.<br>
            > <br>
            > Here's another path we could take:<br>
            > <br>
            > 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.<br>
            > 2) Sync the forked repository to the llvm repository,
            delete the llvm repository, rename "bugs" to "llvm", and
            make it public.<br>
            > <br>
            > 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.<br>
            > <br>
            > <br>
            > 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:<br>
            > <br>
            >  * We end up with one single issue tracking system
            containing all issues, both old and new, both open and
            closed.<br>
            >  * All links and references to existing bugs still
            work.<br>
            >  * We have a single bug numbering system covering all
            bugs, and old bugs retain their numbers.<br>
            <br>
            Why are the bug numbers important?</blockquote>
          <div><br>
          </div>
          <div>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.)</div>
        </div>
      </div>
    </blockquote>
    <p>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.<br></p></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>(I don't have any quick fixes for your other mentioned cases.)</p></div></blockquote><div>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 :)]</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          
          <div>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.</div>
          <div><br>
          </div>
          <div>(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.)</div>
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Could you help give some
            example use cases that require having<br>
            a non-intersecting set of bug numbers for bugzilla bugs and
            github issues?<br>
          </blockquote>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            -Tom<br>
            <br>
            <br>
            > <br>
            > 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?<br>
            > <br>
            >     Philip<br>
            > <br>
            >     On 4/20/20 4:08 PM, James Y Knight via llvm-dev
            wrote:<br>
            >>     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:<br>
            >>     1. If the migration is messed up, the repo can
            be deleted, and the process run again, until we get a result
            we like.<br>
            >>     2. The numbering can be fully-controlled.<br>
            >>     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.<br>
            >><br>
            >>     We could also just have <a href="http://llvm.org/PR#%23%23" rel="noreferrer" target="_blank">llvm.org/PR###</a>
            <<a href="http://llvm.org/PR#%23%23" rel="noreferrer" target="_blank">http://llvm.org/PR#%23%23</a>>
            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, <a href="https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html</a>).<br>
            >><br>
            >>     Then we could introduce a new naming scheme for
            github issue shortlinks.<br>
            >><br>
            >>     On Mon, Apr 20, 2020 at 3:50 PM Richard Smith
            via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>
            wrote:<br>
            >><br>
            >>         On Mon, 20 Apr 2020 at 12:31, Tom Stellard
            via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>
            wrote:<br>
            >><br>
            >>             Hi,<br>
            >><br>
            >>             I wanted to continue discussing the
            plan to migrate from Bugzilla to Github.<br>
            >>             It was suggested that I start a new
            thread and give a summary of the proposal<br>
            >>             and what has changed since it was
            originally proposed in October.<br>
            >><br>
            >>             == Here is the original proposal:<br>
            >><br>
            >>             <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html</a><br>
            >><br>
            >>             == What has changed:<br>
            >><br>
            >>             * You will be able to subscribe to
            notifications for a specific issue<br>
            >>               labels.  We have a proof of concept
            notification system using github actions<br>
            >>               that will be used for this.<br>
            >><br>
            >>             * Emails will be sent to llvm-bugs when
            issues are opened or closed.<br>
            >><br>
            >>             * We have the initial list of labels: <a href="https://github.com/llvm/llvm-project/labels" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/labels</a><br>
            >><br>
            >>             == Remaining issue:<br>
            >><br>
            >>             * There is one remaining issue that I
            don't feel we have consensus on,<br>
            >>             and that is what to do with bugs in the
            existing bugzilla.  Here are some options<br>
            >>             that we have discussed:<br>
            >><br>
            >>             1. Switch to GitHub issues for new bugs
            only.  Bugs filed in bugzilla that are<br>
            >>             still active will be updated there
            until they are closed.  This means that over<br>
            >>             time the number of active bugs in
            bugzilla will slowly decrease as bugs are closed<br>
            >>             out.  Then at some point in the future,
            all of the bugs from bugzilla will be archived<br>
            >>             into their own GitHub repository that
            is separate from the llvm-project repo.<br>
            >><br>
            >>             2. Same as 1, but also create a
            migration script that would allow anyone to<br>
            >>             manually migrate an active bug from
            bugzilla to a GitHub issue in the llvm-project<br>
            >>             repo.  The intention with this script
            is that it would be used to migrate high-traffic<br>
            >>             or important bugs from bugzilla to
            GitHub to help increase the visibility of the bug.<br>
            >>             This would not be used for mass
            migration of all the bugs.<br>
            >><br>
            >>             3. Do a mass bug migration from
            bugzilla to GitHub and enable GitHub issues at the same
            time.<br>
            >>             Closed or inactive bugs would be
            archived into their own GitHub repository, and active bugs<br>
            >>             would be migrated to the llvm-project
            repo.<br>
            >><br>
            >><br>
            >>         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 <a href="http://llvm.org/PRxxxxx" rel="noreferrer" target="_blank">llvm.org/PRxxxxx</a>
            <<a href="http://llvm.org/PRxxxxx" rel="noreferrer" target="_blank">http://llvm.org/PRxxxxx</a>>,
            and if we can preserve all the issue numbers this would ease
            the transition pain substantially.<br>
            >>          <br>
            >><br>
            >>             The key difference between proposal 1,2
            and 3, is when bugs will be archived from bugzilla<br>
            >>             to GitHub.  Delaying the archiving of
            bugs (proposals 1 and 2) means that we can migrate<br>
            >>             to GitHub issues sooner (within 1-2
            weeks), whereas trying to archive bugs during the<br>
            >>             transition (proposal 3) will delay the
            transition for a while (likely several months)<br>
            >>             while we evaluate the various solutions
            for moving bugs from bugzilla to GitHub.<br>
            >><br>
            >><br>
            >>             The original proposal was to do 1 or 2,
            however there were some concerns raised on the list<br>
            >>             that having 2 different places to
            search for bugs for some period of time would<br>
            >>             be very inconvenient.  So, I would like
            to restart this discussion and hopefully we can<br>
            >>             come to some kind of conclusion about
            the best way forward.<br>
            >><br>
            >>             Thanks,<br>
            >>             Tom<br>
            >><br>
            >>           
             _______________________________________________<br>
            >>             LLVM Developers mailing list<br>
            >>             <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
            >>             <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
            >><br>
            >>       
             _______________________________________________<br>
            >>         LLVM Developers mailing list<br>
            >>         <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
            >>         <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
            >><br>
            >><br>
            >>     _______________________________________________<br>
            >>     LLVM Developers mailing list<br>
            >>     <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
            >>     <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
            >     _______________________________________________<br>
            >     cfe-dev mailing list<br>
            >     <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
            <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
            >     <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
            > <br>
            > <br>
            > <br>
            > _______________________________________________<br>
            > LLVM Developers mailing list<br>
            > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
            > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
            > <br>
            <br>
            _______________________________________________<br>
            LLVM Developers mailing list<br>
            <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
            <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
  </div>

_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>