<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    I tried to clean up bugzilla bugs about a year ago. 620 doesn't
    sound like a lot but i gave up after about 20 or so.<br>
    <br>
    A lot of the early bugs are Objective-C-related because that's where
    it all began - the retain count checker. We basically had one
    checker and people called it "The Checker". There was also no
    interprocedural analysis at all.<br>
    <br>
    I don't think there's an existing policy so let's try to come up
    with something.<br>
    <br>
    It's pretty unlikely that you'll get replies on 10-year-old bugs.
    You can try to ping the bug (all CCd people including the author
    will receive an email notification) but if it ends up having
    insufficient information there's not much we can do.<br>
    <br>
    Generally, i think it's much better to start with *new* bugs and
    work backwards. Fresh bugs are more likely to be relevant, the
    author is more likely to be available for discussion, and addressing
    them quickly will make them happy.<br>
    <br>
    Having a reproducer is a must for a good bug report. It doesn't have
    to be small, especially given that false positives can't be
    automatically reduced. We also shouldn't ask people to reduce by
    hand as long as they're allowed to provide a full preprocessed file,
    because not only we have enough tools to debug an unreduced bug but
    also it's still very easy to accidentally remove essential bits of
    the puzzle when you're reducing by hand.<br>
    <br>
    If your best effort to reproduce fails and the author is not
    responding, closing an old bug as "works for me" is always a valid
    option. I don't think there's much value in building an ancient
    clang to reproduce the issue and bisecting find the exact commit
    that fixed.<br>
    <br>
    Once a reproducer is obtained, the next step is to debug the bug.
    This step is not absolutely necessary as whoever finds the bug
    report will be able to do that anyway but it can often be done much
    faster than fixing the bug and also that's the only way to properly
    categorize the bug report (find duplicates, assign to umbrella bugs,
    etc.). It's usually very hard to guess the root cause just by
    looking at the report but exploded graph debugging usually yields
    the exact answer. So i usually try to do that. Especially when the
    report is about something that i thought was working perfectly.<br>
    <br>
    As for categorization, i'm making "umbrella" bugs for large issues
    that affect many users and get reported often. I tag these bugs as
    [Umbrella] and for now there's three of them (you've already seen
    two). The individual instances are duped to them and the dupe count
    is supposed to indicate how big of a problem it is (i don't think
    it's actually working though).<br>
    <br>
    Finally, please cc me if you find something interesting ^.^<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 12/26/20 5:49 AM, Vince Bridgers via
      cfe-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEgb0iCTi-8JYRJ1jGKQhMmn68zyLNbmStZchEOi570b_Yyktw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi all, I looked through the Bugzilla database for
        the static analysis component. I was wondering what, if any,
        cleanup policy exists for long standing bugs. I found 620 bugs
        today. While I did not systematically look at each and every one
        one those :)  I noticed in passing many were in one of the
        following various states:
        <div><br>
          <div>1) A duplicate</div>
          <div>2) An issue that had already been solved</div>
          <div>3) An issue that's not concrete, or has enough
            information to start with. </div>
          <div>4) Some (many?) of which the originator cannot be
            contacted for further clarification. </div>
          <div><br>
          </div>
          <div>Most of these are Assigned to Ted (especially the ones
            filed before 2018). </div>
          <div><br>
          </div>
          <div>Artem and/or Devin: Is there a policy we're following if
            we want to just start going through these issues, triage and
            cleanup the easier ones? </div>
          <div><br>
          </div>
          <div>May I suggest the following?</div>
          <div><br>
          </div>
          <div>1) Maybe for the older ones, we can prove they are fixed
            and close them, documenting how they were proven to be fixed
            in the bug, leaving an audit trail?<br>
          </div>
          <div>2) For ones that are not concrete, vague or have a
            reproducer, start a discussion on the mailing list, attempt
            to contact the originator? And after an appropriate time,
            close the bug as not reproducible? </div>
          <div>3) Mark duplicates in favor of a more complete
            description of the issue?</div>
          <div><br>
          </div>
          <div>Please let me know if you have strong preferences to
            initiate a cleanup, and I'm happy to follow those. I'm also
            willing to lead and contribute to a cleanup effort. </div>
          <div><br>
          </div>
          <div>Best</div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>