<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>