Re: Killing old dead bugs

[Eric Gallager <egall at gwmail dot gwu dot edu>]

On 7/18/17, Yuri Gribov <tetra2005@gmail.com> wrote:
> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor <msebor@gmail.com> wrote:
>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>
>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor <msebor@gmail.com> wrote:
>>>>
>>>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>>>>
>>>>>
>>>>> Hi Mikhail,
>>>>>
>>>>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev <maltsevm@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>>>>>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>>>>
>>>>>
>>>>>
>>>>> Replies in your link suggest to leave a final comment in bugs with
>>>>> explanatory suggestion to close them so that maintainers who read
>>>>> gcc-bugs list hopefully notice them and act appropriately.
>>>>> Unfortunately I found this to _not_ work in practice. Below you can
>>>>> see a list of bugs I've investigated (and often bisected) in the past
>>>>> weeks - none of them were closed by maintainers (or at least
>>>>> commented).
>>>>>
>>>>> So I'm afraid we have to conclude that there's no working process to
>>>>> close stale bugs in place (which may be one of the reasons of bugcount
>>>>> growth).
>>>>
>>>>
>>>>
>>>> The informal process that some (most?) of us have been following
>>>> is to close them with a comment explaining our rationale.
>>>> It's good to fill in the Known to fail/Known to work versions if they
>>>> can be determined.  Mentioning the commit that fixed the bug as
>>>> you did for the bugs below is ideal.  Adding a test case if one
>>>> doesn't exist in the test suite is also very useful, though quite
>>>> a bit more work.  In my experience, if a bug is closed that should
>>>> stay open, someone usually notices pretty quickly and reopens it,
>>>> so I wouldn't be too worried about doing something wrong.
>>>
>>>
>>> Martin,
>>>
>>> Firstly, thanks for detailed explanation.
>>>
>>> What to do about bugs originating in upstream packages?  I noticed
>>> they sometimes get closed with "RESOLVED MOVED" resolution
>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>>> does not happen and they just hang in tracker forever for no good
>>> reason.
>>>
>>> Actually what I tried to emphasize is that it's impossible for a
>>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>>> rights to close bugs) to contribute to project by cleaning stale bugs,
>>> because requests to close them are mostly ignored (because
>>> maintainers, obviously, have much more interesting work to do).
>>
>>
>> I take your point.  I didn't realize closing bugs was restricted.
>> Given the work you've done on the bugs below (and elsewhere) you
>> should be able to close them.  If you aren't and would like to be
>> able to, please request it by emailing overseers@gcc.gnu.org ((at
>> least I think that's the right way to go about it), or follow up
>> here and I'm sure someone with the right karma will make it happen.
>
> Jonathan also mentioned something not immediately obvious in IRC:
> logging into BZ with gcc.gnu.org account provides elevated privileges.
> So if you have write access, you should get extra BZ rights for free.
>

Is there a way to do this with a password thru a graphical web
browser? The instructions I found on the SVN write page
<https://gcc.gnu.org/svnwrite.html> only mentioned ssh-ing into the
server. It says "Your gcc.gnu.org account... is what you use for
Bugzilla" but doesn't actually say how to do that. I tried using the
same password as I do for the Bugzilla account linked to the email
that my gcc.gnu.org account forwards to (this one), but that didn't
work. Sorry if I'm missing something obvious...

>>>> The process for managing bugs is in more detail described here:
>>>>
>>>>   https://gcc.gnu.org/bugs/management.html
>>>>
>>>> If you think it should be clarified in some way please feel free
>>>> to send in a patch.
>>>>
>>>> Martin
>>>>
>>>>
>>>>>
>>>>> * Bug 41992 - ICE on invalid dereferencing of void *
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
>>>>> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
>>>>> underlying type
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
>>>>> * Bug 61693 - [asan] is not intercepting aligned_alloc
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
>>>>> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
>>>>> format mismatch between libasan and GCC
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
>>>>> * Bug 78028 - ASAN doesn't find memory leak
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
>>>>> * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
>>>>> "Unsupported arch"
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
>>>>> * Bug 78654 - ubsan can lead to excessive stack usage
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
>>>>> * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
>>>>> headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
>>>>> * Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
>>>>> * Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
>>>>> * Bug 54123 - inline functions not optimized as well as static inline
>>>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)
>>>>>
>>>>> -Y
>>>>>
>>>>
>>
>