On 7/19/17, Yuri Gribov <tetra2...@gmail.com> wrote: > On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager <eg...@gwmail.gwu.edu> > wrote: >> On 7/18/17, Yuri Gribov <tetra2...@gmail.com> wrote: >>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor <mse...@gmail.com> wrote: >>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote: >>>>> >>>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor <mse...@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 <malts...@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 overse...@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. > > AFAIR the only way to login to BZ with GNU account is to reset > password (so that BZ sends reset email to the linked account which you > specified via `ssh usern...@gcc.gnu.org email ...'). >
Thank you; your advice worked! I shall now proceed to killing some old dead bugs of my own, since this conversation seemed to encourage it... >> 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 >>>>>>> >>>>>> >>>> >>> >
