[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: DrKonqi and BKO
From:       Martin Klapetek <martin.klapetek () gmail ! com>
Date:       2016-11-03 1:09:27
Message-ID: CAPLgePpOqOmV=oCsJ0zKNEYwvuAvk8V79dxKOz5WgnMYQ=V5ow () mail ! gmail ! com
[Download RAW message or body]

On Wed, Nov 2, 2016 at 6:32 AM, Harald Sitter <sitter.harald@gmail.com>
wrote:

> On Wed, Nov 2, 2016 at 11:04 AM, René J. V.  Bertin <rjvbertin@gmail.com>
> wrote:
> > Martin Klapetek wrote:
> >
> >
> >> For improving readability, there is bugzilla-traceparser plugin, that
> can
> >> dynamically
> >> hide looooooooong backtraces with a bit of JS magic to expand them and
> much
> >> more
> >> like finding duplicates and also auto-dupe. I still think this would
> help
> >> tremendously to
> >> all our bugzilla users.
> >
> > Yes, long inline backtraces do not make it easier to navigate a bug
> report.
> >
> > Still, the best thing would be a formal way to attach a backtrace, e.g.
> as an
> > attachment with a standardised name. I'm thinking of a dedicated entry
> field on
> > the bug entry webpage and programmatic hooks to upload and query these
> > attachments.
>
> Bug trackers are not trace trackers. Spending time on solving the
> actual problem is the best thing https://retrace.fedoraproject.org/
> https://errors.ubuntu.com/


They're not, yet we're using it as one. So might as well improve
the experience at least a bit.

Cheers
-- 
Martin Klapetek

[Attachment #3 (text/html)]

<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">&lt;<a \
href="mailto:sitter.harald@gmail.com" \
target="_blank">sitter.harald@gmail.com</a>&gt;</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 &lt;<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>&gt; \
wrote:<br> &gt; Martin Klapetek wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; For improving readability, there is bugzilla-traceparser plugin, that \
can<br> &gt;&gt; dynamically<br>
&gt;&gt; hide looooooooong backtraces with a bit of JS magic to expand them and \
much<br> &gt;&gt; more<br>
&gt;&gt; like finding duplicates and also auto-dupe. I still think this would \
help<br> &gt;&gt; tremendously to<br>
&gt;&gt; all our bugzilla users.<br>
&gt;<br>
&gt; Yes, long inline backtraces do not make it easier to navigate a bug report.<br>
&gt;<br>
&gt; Still, the best thing would be a formal way to attach a backtrace, e.g. as \
an<br> &gt; attachment with a standardised name. I&#39;m thinking of a dedicated \
entry field on<br> &gt; the bug entry webpage and programmatic hooks to upload and \
query these<br> &gt; 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&#39;re \
not, yet we&#39;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>



[prev in list] [next in list] [prev in thread] [next in thread]