[RFC] Re: Disable DrKonqi for KWin in stable releases

[Thomas Lübking]

tl;dr - No.

1st off i recall somebody more or less saying not letting any distro (and one in particular) determine his (or her, hey ;-) actions.
I agree with that.

Furthermore, it's not much fair towards "other users" - and loosing high-quality reports (eg. from gentoo) because <placereasonhere> is less than ideal on either side.

2nd there are good bug reports after all, as just appeared bug #319107

3rd it's not a nice attitude to tell the user "i'm not interested in your problems" - not without at least telling him why and i'm not sure whether this explanation ("because we're spammed by ubuntu users"?) should rise.
Even if it's a bug in the driver, the user cannot possibly figure that and needs a developers comment.
Otherwise the perception is just "kwin is crashy crap" - whether because his driver installation got nuked or he uses a "development only!" driver, s/he completely does not know. "KWin crashes! All teh tiem!! Period!!!!1!!"

4th because ignoring the problem does not solve the problem.
What about other GL clients? (krita, gwenview etc.)

And what do you think is gonna happen next?
KWin crashes on the broken driver, then disables compositing.
So you'll get a "compiz not works" bugreport where you first need a dictionary to guess what he meant to say.
Then you'll have to either declare that "up/downstream" based on no information or tell him to gdb into kwin from VT1 (yeaaahhh!!!)
After you had the pleasure to interrogate him on what does not work and why, you'll end up with a "KWin is crashy crap and the devs are sucking assholes who can't help me" user for each of the reported dupes.

So, you'd have to catch SIGSEGV and dump the stack to some file which the user can then provide. Win? None.

Yes, some users (of esp. one distro) seem too dumb to read themselves out of a wet paperbag but it /must/ be possible to forcefully redirect even the last idiot to the most likely dupe when they click the "report" button, tell them to please check whether this seems the same (by explanation and backtrace) and if they click "yes", just dupe it.
If that still does not work (big fat green "yes" button and tiny grayish "no" link), maybe even just optimistically dupe it and have devs fix that in the (rare) false positive case.

5th because the above or any other solution will also still provide us with ideas on how much a widespread problem the bug is ("do we better add a workaround like deactivating a feature on some chip?")

Yes, the situation is crap.
Yes, we'll see many more "broken fglrx installation" issues in the near future.
No, i am *not* willing to surrender! Esp. not to youknowwho ;-)

If DrKonqui cannot be fixed to guide the user through the dupes, just let the bugs come. Ignore them, i'll dupe them every evening.


Cheers,
Thomas

On Dienstag, 30. April 2013 13:37:51 CEST, Martin Gräßlin wrote:
> Hi all,
>
> <tldr>KWin gets too many crash reports, let's disable DrKonqi</tldr>
>
> the latest post-Ubuntu-release crash report flood made me think 
> that all the 
> crashes we get are only causing work. There is no value in it 
> except that we 
> know that KWin once again crashed because Ubuntu is 
> *insertrandominsulthere*. 
> My initial idea was to discuss with Jonathan and Harald whether we could 
> disable crash reporting just on Ubuntu.
>
> But thinking more about it: there is no benefit at all in the crash reports 
> reported against stable packages. It's all upstream or downstream issues. 
> Since January 1st, 132 crash reports were created but only 10 of them have 
> been fixed. Out of these 10 fixed reports only two are for 
> 4.10.0 (with one of 
> them from a Kubuntu dev running pre-alpha of raring) and one is for 4.10.1. 
> All the other reports are for the alphas and betas.
>
> My suggestion is therefore to push the following patch to 
> stable branch and to 
> future stable branches on final tagging day:
> diff --git a/kwin/main.cpp b/kwin/main.cpp
> index ed051f8..710c16d 100644
> --- a/kwin/main.cpp
> +++ b/kwin/main.cpp
> @@ -273,6 +273,7 @@ Application::Application()
>      connect(&owner, SIGNAL(lostOwnership()), SLOT(lostSelection()));
>  
>      KCrash::setEmergencySaveFunction(Application::crashHandler);
> +    KCrash::setDrKonqiEnabled(false);
>      crashes = args->getOption("crashes").toInt();
>      if (crashes >= 4) {
>          // Something has gone seriously wrong
>
> We would still get the crash reports in master and during beta and RC for 
> which we are interested, but all the junk would be disabled.
>
> The nice side effect would be that it would look like improved quality as 
> normaly a user wouldn't notice a KWin crash. It's a short 
> flicker during which 
> the window decorations got recrated, but that's it. Has there 
> been a crash if 
> nobody is there to notice it?
>
> Opinions? Can somone convince me to not do it?
>
> --
> Martin Gräßlin
>