Re: Disabling whoopsie by default in the 12.04.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dylan McCall wrote on 06/08/12 18:49: > > On Mon, Aug 6, 2012 at 6:20 AM, Matthew Paul Thomas > ... >> >> That isn't true, unless today is a freak exception. Right now, >> out of the 50 most common errors, only 17 are from services. The >> rest are from applications. > > Isn't that _reported_ errors? Do you have any numbers for error > popups that have been dismissed? Dismissing the error alert sends an error report by default. Because no extra effort is required, we can be confident that errors reported are fairly representative of errors occurring. Errors go unreported if you log out without dismissing the alert, if you uncheck the checkbox before dismissing the alert, if your admin has blocked error reporting in System Settings, or if there's a bug in Apport or Whoopsie. We don't have numbers on unreported errors because they are, you know, unreported. :-) > Personally, I almost always dismiss the system error popups. They > are vaguely worded and usually for the same problem in > mission-control. The application errors, on the other hand, are > upfront about what is broken. It's likely I have just seen that > application crashing. I know (and care about) whatever is going > on. Oh, it also helps that lots of background stuff loves to crash > during shutdown / suspend / resume (resulting in crash popups when > I log in), while application crash popups are at slightly less > annoying, and more meaningful, moments. I'm willing to accept that > I could be an exception, but I suspect the numbers of reported > errors might be biased in this way. Until yesterday I didn't know that error alerts were appearing for errors that occurred in the previous session. It isn't appropriate to prompt about those (unless they directly caused the session exit). So what we need now is a way to distinguish those from the rest. <http://launchpad.net/bugs/1033932> > ... > > PS: For what it's worth, Microsoft's Action Centre thing from > Windows 7 might actually be an interesting model for this. It is > mostly a useless thing that nags people to set up backups, but it > also has a nice bit that lists collected system errors. It's useful > to actually diagnose problems that are occurring. In Ubuntu all we > seem to do is nag the user to report errors (which are promptly > forgotten), and there's no real sense of getting something back for > the trouble. What if that data was aggregated locally, too, so a > user could see that a particular component is crashing really > frequently? Or report issues from crash popups that had been > previously dismissed? It might make the whole thing more agreeable > ;) We've planned a "Show Previous Reports" button in the settings panel, that goes to a Web page listing the reports you've sent. <https://wiki.ubuntu.com/ErrorTracker#previous> And eventually, the error alert will be able to invite you to install updates because an update is available that fixes the specific problem. <https://wiki.ubuntu.com/ErrorTracker#updates> - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAg/sIACgkQ6PUxNfU6ecq/+ACfXHxAUIZXTyzKyIa+Cb3briOA erIAoMLny/34XMrEc5KcoCvceRRSrCvO =hkBQ -END PGP SIGNATURE- -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Paul Thomas wrote on 06/08/12 12:04: > ... > > An average of 1.4 crashes/user/calendar-day is far too high. > Suppressing the error messages won't fix that. Only fixing the > errors will. > > ... Correction: Steve Langasek's comment that "the value on this graph will always be >= 1" has helped us realize that we're doing the calculation wrong. We're dividing the number of error reports by the number of machines reporting that day. What we actually want is to divide by the *total* number of machines from which their users would typically send error reports. We can't know that exactly, but we can get much closer by using the number of machines that have sent any error reports in the past 90 days. <http://launchpad.net/bugs/1033913> That won't require any client-side changes. It's likely that will result in the average going below 1.0. So the "ten error prompts per week" is almost certainly an overstatement. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAg7rcACgkQ6PUxNfU6ecrNpACcCWXPamwJmICDuAeBWNPzWESm N0sAoKNxR9kOomkwmIfZ9xM0n3T/QY6+ =n455 -END PGP SIGNATURE- -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastien Bacher wrote on 06/08/12 17:27: > ... > > Let me change the angle of my suggestion, and say "we can't keep > the LTS with that number of error prompts", that's my position. > > ... In an ideal world, there would be no alert boxes of any sort. I look forward to the time when people using Ubuntu can go for weeks without seeing an error message, whether from whoopsie or anything else. But optimizing purely for the number of error prompts is the wrong goal. The situations we're discussing are situations where *something has already gone wrong*. We then have a choice between explaining what went wrong, or leaving it a mystery. It may be hard for Ubuntu contributors to appreciate the need to explain what just went wrong, because Ubuntu contributors are self-selected to be familiar with the situation where errors go unexplained. And so instead you focus on things like how many people will be working on fixing errors in 12.04.1. But that isn't actually relevant to the choice of whether to explain errors to users or not. Now, you propose that so few of the crashes in Ubuntu 12.04.1 need to be explained, that *none* of them should be. But you haven't provided any data to support this. The claim that most crashes are in services isn't supported by the evidence. (Of the most common reported errors, yesterday 17/50 were; today only 7/50 were.) If we can isolate particular classes of error that we can be confident don't need explaining, then great! Let's not show an error prompt for those. (We could batch up the error reports, and send them next time an error occurs that does need to be explained.) For example, perhaps you could describe how to identify errors that happened at logout or shutdown. Cheers - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAg5DAACgkQ6PUxNfU6ecrODwCeOqOXerbHLaPrwYHb3OYggM7U CO4AoNJwJ9RoIn/SAS5StTYnTv9JIW/c =fMB/ -END PGP SIGNATURE- -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastien Bacher wrote on 06/08/12 12:48: > > Le 06/08/2012 13:04, Matthew Paul Thomas a écrit : >> >> - It makes relaunching a crashed application much easier. > > Right, most of the issues we get are with services and not > applications though That isn't true, unless today is a freak exception. Right now, out of the 50 most common errors, only 17 are from services. The rest are from applications. >> - From the next errors.ubuntu.com rollout, it will let release >> managers and other contributors see whether Ubuntu Q is more >> reliable than 12.04. > > I never suggested turning of whoopsie in Q, so we will get metrics > in Q in any case. We have metrics from precise at release time and > .1 time, that should be good enough to know where Q stands. I don't > think lacking a metrics on 12.04.1 post .1 compared to Q is a big > deal, the LTS shouldn't change much, we want to know where Q stands > though and we will know since we will keep the system running for > it. I think that is mistaken in three ways. Most importantly, Ubuntu 12.04.1 does not mark the end of updates to 12.04. There will be more SRUs. Hopefully some of those will make 12.04 more reliable. If we're unlucky, others may make it less reliable. If the latter happens, how will you know? Second, the kind of people who install 12.04.1 (or buy a computer with it installed) may have noticably different behavior from the kind of people who installed 12.04 -- using different applications and features, and encountering errors at different rates. And third, there may be time-based problems that people using 12.04 can't have encountered yet (unless their clock was set wrong). >> With previous versions of Ubuntu, windows would disappear or >> features would stop working, and people wouldn't know why. The >> only difference is that now the failure comes with an >> explanation. It would be best if the failure didn't occur at all, >> but if it does, it's better for it to be explained than to be >> mysterious. > > That's again assuming that the errors we received are real bugs > having an user visible impact, it's true in some cases but I would > challenge that being the most frequent case, we have been looking > at those errors for 3 months and most of them are bugs reported > against services, or happening at session closing, or harmless > exception uncaught in python programs. As above, most of them are not against services. And even if they were, so what? If Bluetooth stops working, for example (a couple of today's top 50 are in blueman), explaining the error can help someone understand that a Bluetooth connection failed because of a problem with Ubuntu, not because they made a mistake. Same if sessioninstaller fails, or aptdaemon. >> Turning off error reporting would leave the release team >> ignorant about whether 12.10 is an improvement on 12.04. But this >> is not a release-team-specific question. It would make Ubuntu >> developers in general less productive, and it would make Ubuntu >> worse for end users. > > The suggestion is to turn if off for 12.04.1, can you explain how > it prevents us to get metrics on 12.10? I didn't say it prevents you from getting error reports from 12.10. I said it prevents you from seeing whether 12.10 is better or worse than 12.04. By "12.04" I include 12.04.1 and any later updates. >> If you think there are ways the end-user presentation can be >> improved, I'm happy to take suggestions. Routing around that by >> asking the release team to disable it altogether is not cool. > > Evan said that work was ongoing on "batching reports to submit > several together", that will be good. I don't think there is > magical ways around it otherwise, it's just that 10 bugs a week is > too much errors dialog popping up. That is shooting the messenger. Yes, ten errors a week is too many. Suppressing the error alerts doesn't make that better, it makes it worse. It's a choice between unreliable, and unreliable + unhelpful. > The main concern is that only a small fraction of those are user > visible issue. How do you know? > To take an example a non marginal number of issues happen on > session closing, they are due to the fact that our desktop session > management is not really good. That's a known issue, will not be > fixed in the LTS (the scope of the work is not appropriate for > stable updates), and is harmless ... still it means lot of users > get a "system error happened" dialog first thing after next login. > That has a real cost in user perception, the benefit we get back is > null though ..
Re: Disabling whoopsie by default in the 12.04.1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastien Bacher wrote on 02/08/12 22:31: > ... > > That's something quite some people raised as an issue since > precise, the frequent whoopsie dialogs in the LTS gives users the > feeling that precise is unstable Maybe 12.04 is more stable than any previous version of Ubuntu. Maybe it is more stable than Fedora, or Suse, or Debian. But you don't know that, precisely because those other OSes don't have this kind of error reporting. So how do you know that "the feeling that precise is unstable" is not actually justified? An average of 1.4 crashes/user/calendar-day is far too high. Suppressing the error messages won't fix that. Only fixing the errors will. > (it seems often qualified to buggier over previous release for no > reason out of the number of error dialogs showing up to report > bugs). They don't show up to report bugs. (That's not even an option, unless you've altered crashdb.conf.) They show up to explain why something just went wrong -- and, if it was an application crashing, to let you relaunch it. > I've discussed the issue with different people in different teams, > here is my try to a summary of the pro and con: > > Pro: > > - it gives us infos on what issues users run into > > - it gives feedback to users on what happen when a program close > while they are using it - - It makes relaunching a crashed application much easier. - - From the next errors.ubuntu.com rollout, it will let release managers and other contributors see whether Ubuntu Q is more reliable than 12.04. > Con: > > - it's showing up too often and giving the impression to users that > the system is buggy > > ... With previous versions of Ubuntu, windows would disappear or features would stop working, and people wouldn't know why. The only difference is that now the failure comes with an explanation. It would be best if the failure didn't occur at all, but if it does, it's better for it to be explained than to be mysterious. Turning off error reporting would leave the release team ignorant about whether 12.10 is an improvement on 12.04. But this is not a release-team-specific question. It would make Ubuntu developers in general less productive, and it would make Ubuntu worse for end users. If you think there are ways the end-user presentation can be improved, I'm happy to take suggestions. Routing around that by asking the release team to disable it altogether is not cool. Martin Pitt wrote on 03/08/12 03:46: > > Apport as it was on precise (and still is in Quantal) has not > really been designed for usage in a stable release. For example, > the rate limitation should be a lot more aggressive in stables, The rate limitation should be removed altogether, because it's causing some crashes to go unexplained. (It's also skewing the statistics, though that's less important.) > and we need to do something about the presentation of crashes that > are not obviously connected to the UI, such as crashes in threads > and respawned services. > > ... Currently we're incorrectly showing the application crash alert for a thread crash. The thread crash alert includes an "Ignore future problems of this type" checkbox, which should alleviate that problem. Hopefully this can be fixed in an SRU. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAfpMYACgkQ6PUxNfU6ecp7TACfdbHlvsfAnWIXeiHnSjB9ApiH MVMAoKGvf+ti+P4a8EIbFiChiBUTkD5E =VzFr -END PGP SIGNATURE- -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
