<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Generally supportive here, but I see a couple of small concerns.<br>
    </p>
    <div class="moz-cite-prefix">On 10/24/19 7:54 PM, James Y Knight via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAA2zVHpdzxBASqMefsRSwkVknFp4n=Smy3gYLywpcLmwCJ5wAw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>We held a round-table at the llvm dev conference about what
          other pieces of Github infrastructure we may want to use. This
          thread in particular is about switching to github issue
          tracking. Use of other parts of Github functionality was also
          discussed -- but that should be for other email threads.</div>
        <div><br>
        </div>
        <div>Most of the ideas here were from other people. I <i>believe</i>
          this proposal represents the overall feeling of the folks at
          the round-table, in spirit if not in exact details, but nobody
          else has reviewed this text, so I can't make any specific such
          claim as to who the "we" represents, other than myself. Just
          assume all the good ideas here were from others, and all the
          bad parts I misremembered or invented.</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><span style="font-size:large">Background</span><br>
        </div>
        ---- 
        <div>
          <div>Our bugzilla installation is...not great. It's been
            not-great for a long time now.</div>
          <div><br>
          </div>
          <div>Last year, I argued against switching to github issues. I
            was somewhat optimistic that it was possible to improve our
            bugzilla in some incremental ways...but we haven't.
            Additionally, the upstream bugzilla project was supposed to
            make a new release of bugzilla ("harmony"), based on <a
              href="http://bugzilla.mozilla.org" moz-do-not-send="true">bugzilla.mozilla.org</a>'s
            fork, which is much nicer. I thought we would be able to
            upgrade to that. But there has been no such release, and not
            much apparent progress towards such. I can't say with any
            confidence that there will ever be. I no longer believe it
            really makes sense to continue using bugzilla.</div>
          <div>
            <div><br>
            </div>
            <div>This year, we again discussed switching. This time,
              nobody really spoke up in opposition. So, this time,
              instead of debating <i>whether</i> we should switch, we
              discussed <i>how</i> we should switch. And came up with a
              plan to switch quickly.</div>
            <div><br>
            </div>
            <div>GitHub issues may not be perfect, but I see other
              similarly-large projects using it quite successfully (e.g.
              rust-lang/rust) -- so I believe it should be good for us,
              as well. Importantly, Github Issues is significantly less
              user-hostile than our bugzilla is, for new contributors
              and downstream developers who just want to tell us about
              bugs!</div>
            <div><br>
            </div>
            <div>
              <div><br>
              </div>
            </div>
            <div><font size="4">Proposal</font></div>
            <div><font face="arial, sans-serif">----</font></div>
            <div>We propose to enable Github issues for the llvm-project
              repository in approximately two weeks from now, and
              instruct everyone to start filing new issues there, rather
              than in bugzilla.</div>
          </div>
        </div>
      </div>
    </blockquote>
    I think two weeks is simply too quick.  Our community is huge,
    there's inherently a delay with information dissemination and we
    want objectors to have a chance to respond.  4-8 weeks would be a
    much more realistic time frame.  <br>
    <blockquote type="cite"
cite="mid:CAA2zVHpdzxBASqMefsRSwkVknFp4n=Smy3gYLywpcLmwCJ5wAw@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
            </div>
            <div>
              <div>Some things we'd like to get in place before turning
                on Github's Issue tracker:</div>
              <div>1. Updated documentation.</div>
              <div>2. An initial set of issue tags we'd like to use for
                triaging/categorizing issues.</div>
              <div>3. Maybe setup an initial issue template. Or maybe
                multiple templates. Or maybe not.</div>
            </div>
            <div><br>
            </div>
            <div>But more important are the things we do <i>not</i> want
              to make prerequisites for turning on Github issues:</div>
            <div><br>
            </div>
            <div>We do <i>not</i> yet plan to turn off Bugzilla, and do <i>not</i> plan
              to migrate the existing issues to GitHub as a prerequisite
              for switching. We will thus expect that people continue
              using bugzilla for commenting on the existing bugs -- for
              the moment.</div>
            <div><br>
            </div>
            <div>We do <i>not</i> want to build supplementary
              notification systems to make github issues send additional
              emails that it is unable to send itself. We will only
              support what GitHub supports. That means:</div>
            <div>- You can subscribe to notification emails for activity
              in the entire llvm-project repository.</div>
            <div>- You can subscribe to notification emails on an
              individual issue.</div>
            <div>- Someone else can CC you on an individual issue to get
              your attention, and you will get notifications from that
              (unless you opt-out).</div>
            <div>- No emails will be sent to <a
                href="mailto:llvm-bugs@llvm.org" moz-do-not-send="true">llvm-bugs@llvm.org</a>
              for github issues.</div>
            <div>- There is no builtin way for users to subscribe to
              emails for bugs that have a given label (for example, all
              "clang" issues, or all x86 issues).</div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>The last two items are *very* unfortunate.  A quick skim through
      the API documentation (<a class="moz-txt-link-freetext" href="https://developer.github.com/v3/issues/">https://developer.github.com/v3/issues/</a>)
      would seem to indicate implementing these fairly straight
      forward.  I think it might be worth implementing our own custom
      scripts here.</p>
    <p>I'm legitimately torn as to whether this should be considered a
      blocker.  I don't actually use either method, so my personal vote
      is no, but I believe others do.  Breaking existing workflows when
      relatively little effort is required not to seems less than idea.</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAA2zVHpdzxBASqMefsRSwkVknFp4n=Smy3gYLywpcLmwCJ5wAw@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
            </div>
            <div><font size="4">Further steps</font></div>
            <div>----</div>
            <div>After we migrate, there's still things we want to do:</div>
            <div><br>
            </div>
            <div>1. Discuss and setup new and better procedures around
              bug triage and prioritization.</div>
            <div><br>
            </div>
            <div>What we have been doing up until now has not been great
              in any case. Switching bug-trackers is a great opportunity
              to try to do something better. E.g., like what the rust
              project has done (<a
href="https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage"
                moz-do-not-send="true">https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage</a>, <a
href="https://forge.rust-lang.org/release/triage-procedure.html#issue-triage"
                moz-do-not-send="true">https://forge.rust-lang.org/release/triage-procedure.html#issue-triage</a>).</div>
            <div><br>
            </div>
            <div>2. Bug migration</div>
            <div><br>
            </div>
            <div><i>After</i> the initial switchover, we do want to
              investigate two possibilities for migrating issues and
              turning off the bugzilla server. I expect which one is
              chosen will come down mostly to feasibility of
              implementation.</div>
            <div><br>
            </div>
            <div>Possibility 1: Migrate <i>all</i> the existing bugs
              into a secondary "llvm-bugs-archive" github repository,
              and then turn off bugzilla. Github offers the ability to
              move bugs from one repository to another, and so we can
              use this to move bugs that are still relevant afterwards
              (potentially this could be done automatically upon any
              activity). Then, shut down bugzilla, and leave behind only
              a redirect script.</div>
            <div><br>
            </div>
            <div>
              <div>Possibility 2: Create the ability to import an
                individual bug from Bugzilla into the llvm-project
                repository by pressing a "migrate this bug to github"
                button. Then, leave bugzilla running only as a static
                snapshot -- as static as possible while leaving the
                "migrate this bug to github" button operational.<br>
              </div>
              <div><br>
              </div>
            </div>
            <div>In both cases, we'd want to support a redirect script
              to take you from the old bug ids to the migrated bug page.
              In both cases, we would <i>preserve</i> the entire
              archive of existing bugs, but would not import the entire
              set into the "llvm-project" github repository. </div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>