https://bugs.kde.org/show_bug.cgi?id=414916

Harald Sitter <sit...@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |NOT A BUG
           Severity|normal                      |wishlist

--- Comment #13 from Harald Sitter <sit...@kde.org> ---
When I feed attachment 124353 into drkonqi git master I get a MayBeUseful score
(that is 2 out of 3 starts) and that is entirely sufficient for bug reporting,
so while unfortunate that it can't reach 3 stars it really does not have any
impact whatsoever on anything.

drkonqi(32202)/(org.kde.drkonqi.parser) BacktraceParser::calculateRatingData:
Rating: 132 out of 144 Usefulness: MayBeUseful

With your specific stack trace it cannot ever be higher than that, and that has
nothing to do with the other threads, they are entirely ignored for rating, as
they should be.

What pulls down the score down are
#12 0x00007f632a53c5bc in ?? ()
#13 0x0000000000000000 in ?? ()
which are of course garbage frames nobody can do anything about.

So... that leaves us with the question of whether there should be a way to get
all missing libraries. I am going to say no to this because the UI is already
very full, specifically the backtrace widget. This is also not nearly as cheap
to implement as it sounds. Because drkonqi only rates the crashed thread it
doesn't even know that other symbols are also missing, so we'd have to first
parse all lines for usefulness which requires refactoring of the rating system
to become stateless. Overall too much time investment for too little gain IMO.

If someone wants to work on something like this, I would instead suggest to
build a CLI tool on top of the existing code that you can feed a backtrace, or
perhaps even a bug number/attachment number, and it will spit out a list of
packages you'd need to install to get a complete backtrace. Or it could also
just install them I suppose. That'd be loads more flexible WRT use cases and
could also easily be exposed in the UI should we choose to find it valuable
enough in the future.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to