<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 2, 2016 at 6:32 AM, Harald Sitter <span dir="ltr"><<a href="mailto:sitter.harald@gmail.com" target="_blank">sitter.harald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 2, 2016 at 11:04 AM, René J. V.  Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br>
> Martin Klapetek wrote:<br>
><br>
><br>
>> For improving readability, there is bugzilla-traceparser plugin, that can<br>
>> dynamically<br>
>> hide looooooooong backtraces with a bit of JS magic to expand them and much<br>
>> more<br>
>> like finding duplicates and also auto-dupe. I still think this would help<br>
>> tremendously to<br>
>> all our bugzilla users.<br>
><br>
> Yes, long inline backtraces do not make it easier to navigate a bug report.<br>
><br>
> Still, the best thing would be a formal way to attach a backtrace, e.g. as an<br>
> attachment with a standardised name. I'm thinking of a dedicated entry field on<br>
> the bug entry webpage and programmatic hooks to upload and query these<br>
> attachments.<br>
<br>
</span>Bug trackers are not trace trackers. Spending time on solving the<br>
actual problem is the best thing <a href="https://retrace.fedoraproject.org/" rel="noreferrer" target="_blank">https://retrace.fedoraproject.<wbr>org/</a><br>
<a href="https://errors.ubuntu.com/" rel="noreferrer" target="_blank">https://errors.ubuntu.com/</a></blockquote><div><br></div><div>They're not, yet we're using it as one. So might as well improve</div><div>the experience at least a bit.<br></div></div><br clear="all"><div>Cheers</div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">Martin Klapetek</span></div></div></div></div>
</div></div>