This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Killing old dead bugs
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.
>>> 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
>>>>
>>>
>