On Thu, Sep 17, 2020 at 4:17 PM Hannah von Reth <vonr...@kde.org> wrote: > > Hi, > > looks like some quoted text is missing. > > I have no idea bout the state of drkonqi on windows, > ages ago a gsoc student did *things* but I don't think anybody was ever > able to use it. > > I can remember a more recent communication that people where trying > again to get it to work.
Ah sorry. The original: > drkonqi is part of plasma, yet it gets built on windows. shall we stop > doing that? windows keeps not having expected plasma requirements > because the rest of plasma is not on windows > > https://build.kde.org/job/Plasma/job/drkonqi/job/kf5-qt5%20WindowsMSVCQt5.14/ > > this already happened a couple weeks ago and was then temporarily > reverted but now it fails again. uselessly I might add. why we even > want to have drkonqi on windows at all is equally questionable as the > platform already has a far superior crash reporting system. I guess the question is mostly.... do we think that pursuing drkonqi on windows is useful at all? The way I see it we'd either want to use the windows error reporting system (to send reports off to microsoft and then get them from there) or we'd need a fair amount of extra code in drkonqi to tie into local-only WER (I'm assuming that's a thing based on the WER API). Since we distribute the binaries we only need a mini dump and the exact build version to then grab our debug symbols for that build and do server-side tracing, so the actual live-tracing feature of drkonqi is fairly uninteresting IMHO. HS
