Hi all, First of all, I'm sorry to create a separate thread on the mailing list, I have disabled all mails from it. I just read the thread about the bug closing protocol thanks to LLVMWeekly. (http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html) I've noticed a lot of reactions from people involved with the solving part of the bugs. So I'm putting out the loggers point of view. (Or at least mine) I'm totally in favor of getting relevant information when a bug gets closed. Over the last couple of years, I've logged several bugs, of which a couple of clang-cl compatibility bugs where put to invalid. Having a good explanation on why this is closed helped me a lot in manually fixing several thousand of occurrences of that pattern. Both mentally to not give up, as by understanding the problem. Please keep doing so! However, from my point of view, this is the tip of an iceberg. Out of about 50 bugs I've logged on a variety of modules, only half reached an end state. (Either fixed or invalid/won't fix). My problem also lies in that other half, those bugs that have been open for more than 2 weeks (upto 5 years). Cause if you don't get a reaction within those 2 weeks, the chances of getting a reaction drop a lot. (Or if reactions suddenly stop) When a bug goes into such a state, you are lost as a bug logger. It took me a couple of years getting our companies code compiling with clang-cl (linking is far future), working around obscure bugs of which I still don't know if you (as community/maintainer) agree if it is a bug. To make matters worse, every time a component gets upgraded (internal library, extrernal library or even the tool-chain, including clang), there is a high probability of firefighting issues. Only when that fails, I spent time logging a bug (as creduce doesn't work on my system). In the best case scenario, I get an event like this weekend that states: merged. This means: I'm certain I'll have a fix in the future. Unfortunately, it is only available in the next official release, which will happen in September. And with a bit of luck, you can find back what the actual revision is, to see the diff. So for now, the code is ifdef-ed out for clang as it won't link anyhow. In conclusion: I really respect the work you do, this puts the standard on a high level. Taking the time to inform the bug logger is a must have. However, it is not the only place were we as bug loggers are lacking information. JVApen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180619/0ad422fa/attachment-0001.html>
Thanks for chiming in - certainly if you get bugs closed that don't reflect when the fix was committed (by revision) that's sub-optimal as well. If someone contributed the fix and are closing the bug because of that contribution, the revision should be mentioned in the bug - if you see cases of that not happening, do please/feel free to reply asking which revision fixed it. Usually when a bug is closed as fixed without a revision it's because the bug wasn't deliberately fixed based on that bug report but perhaps fixed by someone independently stumbling across the same issue - and then no one noticing that it correlated with the bug report for some time. So it's hard to find out which revision. Even in that case, the bug closing should mention which revision the bug was verified to be not present in - so you can at least track that revision to know which release it ends up in & should have the fix (though earlier revisions/releases may also have the fix in them). Thanks, as always, for using Clang & taking the time to file bugs! I know it can be a bit disheartening to file bugs & get no response. If there are particular bugs that continue to plague you, it may be worthwhile to start a thread on llvm-dev about them - things like crashes on valid code with clear/narrow reproducers that affect real users (such as yourself) should get relatively positive responses (as they're easily actionable/clearly motivated). Other things can get a bit more vague & as always, a lot of it comes down to the priorities/availability of the contributors as to whether they have the time, context, etc, to work on the bug fix - unfortunately. (& though it sounds trite, I mean this positively: if you'd like to try your hand at contributing fixes, we hope to be an open & encouraging community to facilitate that :)) - Dave On Mon, Jun 18, 2018 at 10:33 PM JVApen via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > First of all, I'm sorry to create a separate thread on the mailing list, I > have disabled all mails from it. > > I just read the thread about the bug closing protocol thanks to > LLVMWeekly. ( > http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html) > > I've noticed a lot of reactions from people involved with the solving part > of the bugs. So I'm putting out the loggers point of view. (Or at least > mine) > > I'm totally in favor of getting relevant information when a bug gets > closed. Over the last couple of years, I've logged several bugs, of which a > couple of clang-cl compatibility bugs where put to invalid. > Having a good explanation on why this is closed helped me a lot in > manually fixing several thousand of occurrences of that pattern. Both > mentally to not give up, as by understanding the problem. > Please keep doing so! > > However, from my point of view, this is the tip of an iceberg. Out of > about 50 bugs I've logged on a variety of modules, only half reached an end > state. (Either fixed or invalid/won't fix). > > My problem also lies in that other half, those bugs that have been open > for more than 2 weeks (upto 5 years). Cause if you don't get a reaction > within those 2 weeks, the chances of getting a reaction drop a lot. (Or if > reactions suddenly stop) > > When a bug goes into such a state, you are lost as a bug logger. It took > me a couple of years getting our companies code compiling with clang-cl > (linking is far future), working around obscure bugs of which I still don't > know if you (as community/maintainer) agree if it is a bug. > > To make matters worse, every time a component gets upgraded (internal > library, extrernal library or even the tool-chain, including clang), there > is a high probability of firefighting issues. Only when that fails, I spent > time logging a bug (as creduce doesn't work on my system). > > In the best case scenario, I get an event like this weekend that states: > merged. > This means: I'm certain I'll have a fix in the future. Unfortunately, it > is only available in the next official release, which will happen in > September. And with a bit of luck, you can find back what the actual > revision is, to see the diff. So for now, the code is ifdef-ed out for > clang as it won't link anyhow. > > In conclusion: I really respect the work you do, this puts the standard on > a high level. Taking the time to inform the bug logger is a must have. > However, it is not the only place were we as bug loggers are lacking > information. > > JVApen > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180619/3eb91c5b/attachment.html>
On Mon, Jun 18, 2018 at 3:20 PM, JVApen via llvm-dev < llvm-dev at lists.llvm.org> wrote:> To make matters worse, every time a component gets upgraded (internal > library, extrernal library or even the tool-chain, including clang), there > is a high probability of firefighting issues. Only when that fails, I spent > time logging a bug (as creduce doesn't work on my system). >I'm assuming you're on Windows. If you're on Windows 10 you can use creduce under WSL (Windows Subsystem for Linux) and have it call Windows binaries. You just need to make a change to make_tmpdir to use a temp directory that Windows programs have access to. I changed mine to: sub make_tmpdir () { my $dir = File::Temp::tempdir("creduce-XXXXXX", $SAVE_TEMPS ? (CLEANUP => 0) : (CLEANUP => 1), #DIR => File::Spec->tmpdir); DIR => "/mnt/d/temp/"); push @tmpdirs, $dir; return $dir; } Which points to D:\temp which I created for this purpose. I know zero Perl so I haven't made a proper patch to upstream, but hopefully this helps if you ever need to reduce in the future. - Michael Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180619/ce582da0/attachment.html>
Our team internally has gotten creduce working on Windows natively. It wasn't the easiest thing I've ever done, but it took less than an afternoon. Happy to help anyone do this. On Tue, Jun 19, 2018 at 5:51 PM Michael Spencer via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Mon, Jun 18, 2018 at 3:20 PM, JVApen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> To make matters worse, every time a component gets upgraded (internal >> library, extrernal library or even the tool-chain, including clang), there >> is a high probability of firefighting issues. Only when that fails, I spent >> time logging a bug (as creduce doesn't work on my system). >> > > I'm assuming you're on Windows. If you're on Windows 10 you can use > creduce under WSL (Windows Subsystem for Linux) and have it call Windows > binaries. You just need to make a change to make_tmpdir to use a temp > directory that Windows programs have access to. I changed mine to: > > sub make_tmpdir () { > my $dir = File::Temp::tempdir("creduce-XXXXXX", > $SAVE_TEMPS ? (CLEANUP => 0) : (CLEANUP > => 1), > #DIR => File::Spec->tmpdir); > DIR => "/mnt/d/temp/"); > push @tmpdirs, $dir; > return $dir; > } > > Which points to D:\temp which I created for this purpose. I know zero > Perl so I haven't made a proper patch to upstream, but hopefully this helps > if you ever need to reduce in the future. > > - Michael Spencer > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180620/9c856720/attachment.html>
Thanks for taking the time to report bugs! I think you are responsible for filing the most high-quality clang-cl bugs. I hope our bug responses continue to be helpful and informative, but things do often get lost in translation. =/ I also think there's a lot we could do to improve our bug hygiene and processes as a community. The way our bugzilla is configured, pinging bugs does not sent email to llvm-bugs@, so if an issue is not immediately triaged within a week after filing it, it's very unlikely that anyone will ever find it. As a community, we could set up rotations to triage stale bugs, but this takes resources, commitments, and planning. It's eminently doable, but it's not something that any one person or team of contributors can do on their own, so people tend to shy away from disturbing established processes. On Mon, Jun 18, 2018 at 10:33 PM JVApen via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > First of all, I'm sorry to create a separate thread on the mailing list, I > have disabled all mails from it. > > I just read the thread about the bug closing protocol thanks to > LLVMWeekly. ( > http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html) > > I've noticed a lot of reactions from people involved with the solving part > of the bugs. So I'm putting out the loggers point of view. (Or at least > mine) > > I'm totally in favor of getting relevant information when a bug gets > closed. Over the last couple of years, I've logged several bugs, of which a > couple of clang-cl compatibility bugs where put to invalid. > Having a good explanation on why this is closed helped me a lot in > manually fixing several thousand of occurrences of that pattern. Both > mentally to not give up, as by understanding the problem. > Please keep doing so! > > However, from my point of view, this is the tip of an iceberg. Out of > about 50 bugs I've logged on a variety of modules, only half reached an end > state. (Either fixed or invalid/won't fix). > > My problem also lies in that other half, those bugs that have been open > for more than 2 weeks (upto 5 years). Cause if you don't get a reaction > within those 2 weeks, the chances of getting a reaction drop a lot. (Or if > reactions suddenly stop) > > When a bug goes into such a state, you are lost as a bug logger. It took > me a couple of years getting our companies code compiling with clang-cl > (linking is far future), working around obscure bugs of which I still don't > know if you (as community/maintainer) agree if it is a bug. > > To make matters worse, every time a component gets upgraded (internal > library, extrernal library or even the tool-chain, including clang), there > is a high probability of firefighting issues. Only when that fails, I spent > time logging a bug (as creduce doesn't work on my system). > > In the best case scenario, I get an event like this weekend that states: > merged. > This means: I'm certain I'll have a fix in the future. Unfortunately, it > is only available in the next official release, which will happen in > September. And with a bit of luck, you can find back what the actual > revision is, to see the diff. So for now, the code is ifdef-ed out for > clang as it won't link anyhow. > > In conclusion: I really respect the work you do, this puts the standard on > a high level. Taking the time to inform the bug logger is a must have. > However, it is not the only place were we as bug loggers are lacking > information. > > JVApen > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180620/2a6c699c/attachment.html>
So Reid, you'll be running a BoF on this at the October dev meeting? ☺ --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Wednesday, June 20, 2018 6:12 PM To: JVApen at gmail.com Cc: llvm-dev Subject: Re: [llvm-dev] Bug-closing protocol Thanks for taking the time to report bugs! I think you are responsible for filing the most high-quality clang-cl bugs. I hope our bug responses continue to be helpful and informative, but things do often get lost in translation. =/ I also think there's a lot we could do to improve our bug hygiene and processes as a community. The way our bugzilla is configured, pinging bugs does not sent email to llvm-bugs@, so if an issue is not immediately triaged within a week after filing it, it's very unlikely that anyone will ever find it. As a community, we could set up rotations to triage stale bugs, but this takes resources, commitments, and planning. It's eminently doable, but it's not something that any one person or team of contributors can do on their own, so people tend to shy away from disturbing established processes. On Mon, Jun 18, 2018 at 10:33 PM JVApen via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, First of all, I'm sorry to create a separate thread on the mailing list, I have disabled all mails from it. I just read the thread about the bug closing protocol thanks to LLVMWeekly. (http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html) I've noticed a lot of reactions from people involved with the solving part of the bugs. So I'm putting out the loggers point of view. (Or at least mine) I'm totally in favor of getting relevant information when a bug gets closed. Over the last couple of years, I've logged several bugs, of which a couple of clang-cl compatibility bugs where put to invalid. Having a good explanation on why this is closed helped me a lot in manually fixing several thousand of occurrences of that pattern. Both mentally to not give up, as by understanding the problem. Please keep doing so! However, from my point of view, this is the tip of an iceberg. Out of about 50 bugs I've logged on a variety of modules, only half reached an end state. (Either fixed or invalid/won't fix). My problem also lies in that other half, those bugs that have been open for more than 2 weeks (upto 5 years). Cause if you don't get a reaction within those 2 weeks, the chances of getting a reaction drop a lot. (Or if reactions suddenly stop) When a bug goes into such a state, you are lost as a bug logger. It took me a couple of years getting our companies code compiling with clang-cl (linking is far future), working around obscure bugs of which I still don't know if you (as community/maintainer) agree if it is a bug. To make matters worse, every time a component gets upgraded (internal library, extrernal library or even the tool-chain, including clang), there is a high probability of firefighting issues. Only when that fails, I spent time logging a bug (as creduce doesn't work on my system). In the best case scenario, I get an event like this weekend that states: merged. This means: I'm certain I'll have a fix in the future. Unfortunately, it is only available in the next official release, which will happen in September. And with a bit of luck, you can find back what the actual revision is, to see the diff. So for now, the code is ifdef-ed out for clang as it won't link anyhow. In conclusion: I really respect the work you do, this puts the standard on a high level. Taking the time to inform the bug logger is a must have. However, it is not the only place were we as bug loggers are lacking information. JVApen _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180621/201f2d0b/attachment.html>