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