Re: Disabling whoopsie by default in the 12.04.1 release
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 - - 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. 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. 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? 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. The main concern is that only a small fraction of those are user visible issue. 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 ... Cheers, Sebastien Bacher -- 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 ... ... If they are harmless, why do they need fixing at all? If they really don't, that error message in particular could be suppressed. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAfxKMACgkQ6PUxNfU6ecrgBwCgic/5+ZzX0R/M7UYJtfRujlq2 57IAn15H1Zf30fX92SrkgP1X6U9MlLbM =iX97 -END PGP SIGNATURE- -- Ubuntu-release mailing list
Re: Disabling whoopsie by default in the 12.04.1 release
Le 06/08/2012 15:20, Matthew Paul Thomas a écrit : 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. Right, but if you look at e.g jockey issues some are in the backend side of the software, anyway let's not argue over numbers, my gut feeling from dealing with those bugs since precise is that about half of the issues deserve telling the user, the other half are harmless, session closing bugs, etc. If you take a 50%-50% ratio for the sake of the argument with 10 bugs a week you can consider that we spam users 5 times a week for no good reason or that we avoid confusion 5 times a week for them, matter of perspective. We didn't get so many complain in the past about the confusion created by the bugs (but maybe they just didn't reach us) but we do get quite some for the error dialogs... 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? The same way we did until precise, sure it's less ideal but as said it's a cost-benefit ratio and if we don't invest significant resources into actively fixing stable I don't see it moving enough for the datas to provide a benefit over what they cost us. 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. Right, again what's the point to know about issues and bother users if we do nothing about them because we don't have resources allocated to deal with them? And third, there may be time-based problems that people using 12.04 can't have encountered yet (unless their clock was set wrong). Right, it's not optimal, but we didn't have that system until precise and we somewhat managed to do fine, I'm sure we could deal without it for another release. 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. I don't think we need exact numbers to compare 12.10 to 12.04.1+, we know about the current state of 12.04.1 and the release team should set a goal, e.g the medium submission rate should be lower than 1.3 for quantal. While we are doing time based released anyway those goals will need to be hard ones, we can't block on all parameter you need a variable to adjust, either let slip on goals or on time... The main concern is that only a small fraction of those are user visible issue. How do you know? I've been watching errors.ubuntu.com since precise release, dispatching a good number of the top issues and following up with assigned people, we have a good understanding of most of the bugs we fixed, when they happen and what's the impact. If they are harmless, why do they need fixing at all? If they really don't, that error message in particular could be suppressed. They don't, that's my point, we shouldn't bother users about those, but our system is not smart enough at the moment to tell them apport from important issues. Cheers, Sebastien Bacher -- 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
On 08/02/2012 05:31 PM, Sebastien Bacher wrote: Hey, 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 (it seems often qualified to buggier over previous release for no reason out of the number of error dialogs showing up to report bugs). 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 Con: - it's showing up too often and giving the impression to users that the system is buggy - it's often showing programming errors which don't impact users (untracked exception from python softwares or services by example), what users get the most notified about is glitchs about things like ubuntuone services, oneconf, software-center ... most of those are not user visible issues and the frontend would handle the glitches fine without whoopsie notifying the users - errors.ubuntu.com is not good enough yet that we can properly tackle those issues - we don't have the resources to get where we want to be in a short timeframe, we are working on it but meanwhile we are impacting users for things we don't make real use for I know that most of the cons are addressable but until we do address them the consensus form the people I talked to seems to be that the cost-benefit is largely not in our favour at this point so I would recommend we do disable it by default for 12.04.1 to minimize LTS annoyance and keep it enable from now on for new release (on the basis that the system will improve enough that we can catch up and that the perception issues is a bit less of an issue on a non LTS) Just to give some details about the errors.ubuntu.com issues mentioned before (I think people are going to ask what are the problems at some point so I can as well reply to that here): - it's not possible to filter out issues which have been resolved from the list (so it's hard to know what has been worked on and what needs work still) - it's not possible to say what issue happens to what version and get stats of instances of the bugs by version, i.e to get datas on whether the situation improved or not for a bug - some of our engineers have issues login into the system to get access to the infos they need to work on the bugs, that situation is still not resolved after some months - other small issues, but I don't want to turn that email into a list what is wrong currently, especially when we have people knowing about those and working on improving the situation I would add that Evan did an amazing job so far and that errors.ubuntu.com has been proved very useful already (we fixed at least an hundred bugs, most wouldn't have show up in this way using launchpad) so the email is not again that work, we just feel that the current status of the system and the resources allocated to fixing those bugs gives us a situation where the benefit is not sufficient to justify the cost on the Ubuntu image. What do people think about turning whoopsie off for 12.04.1? Cheers, Sebastien Bacher Thanks Sebastien for raising the issue. My point of view on the matter is that whoopsie is a great tool, sending us amazing data that we're only starting to see how to use. I really think we should do anything we can to keep it running on all releases. Now, that being said, my point of view on the user experience is that it sucks, sorry for being a bit harsh here, but let me tell you what happens when I login on most of my 12.04 machines (thankfully I seem to have the buggiest ones so it hasn't been a problem for my friends and relatives). 1) Boot the machine 2) Login 3) Get what looks like a perfectly well working desktop 4) For the next 10 to 15 minutes, getting random apport prompts for everything that blew up since I don't know when (usually last reboot) 4) is especially annoying as these are clearly old crashes that apport for some reason didn't pick up when they happened and have been stacking in /var/crash. I'm guessing some of these happened during session switch or when I wasn't running a desktop environment. In such case I'd expect apport to show me a list of everything that crashed (all 10 of them) and let me just tick the ones I want to submit and then be done with the lot in one go. Instead, I get a flood of apport processes killing my CPU for 15min randomly popping up windows, some asking for my password and some just showing the apport window. I see a few obvious things that might have already been reported as bugs and that if we want to keep whoopsie enabled for 12.04, we should probably fix (with any needed post-release UIFe be granted by the release team if needed): - Either support easy bulk reporting of crashes by showing a single window to the user OR
Re: Disabling whoopsie by default in the 12.04.1 release
Hello everyone. Apologies for the late reply; I was on holiday all last week. Please CC myself and Matthew on replies to this thread as we are not subscribed to the list. Thanks for taking the time to raise this, Seb. On Thu, Aug 2, 2012 at 10:31 PM, Sebastien Bacher seb...@ubuntu.com wrote: 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 (it seems often qualified to buggier over previous release for no reason out of the number of error dialogs showing up to report bugs). 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 Con: - it's showing up too often and giving the impression to users that the system is buggy I think we could argue about whether it's showing up too often. It's showing up precisely as often as the user is experiencing crashes. At present, this is 1.47 times a day on average (a value we wont know if we turn off error reporting). If consensus is that's too often, then we should be focused on bringing that number down by fixing the most pressing issues. Matthew has graciously tackled reducing the number of dialogs on the screen at any one time, a longstanding issue with apport that predates the error tracker. In the future, multiple errors that occur around the same time will be grouped into a single dialog: https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors If getting this into Ubuntu is a top priority for you, let me know and I'll raise it on my list. - it's often showing programming errors which don't impact users (untracked exception from python softwares or services by example), what users get the most notified about is glitchs about things like ubuntuone services, oneconf, software-center ... most of those are not user visible issues and the frontend would handle the glitches fine without whoopsie notifying the users I disagree; these very well may impact users. There is simply no way of knowing whether a background service crashing affects the task the user is currently undertaking. If a DBus service crashes and is automatically restarted, what happens to the application that was partially through a call to that service? What does the graphical interface do? If we disable reporting for these issues, then we'll never know the frequency at which they're occurring or what's causing them. We'll be right back at developers having to chose between failing hard to surface an issue or partially recovering from it and never knowing its true extent or the damage it inflicts. - errors.ubuntu.com is not good enough yet that we can properly tackle those issues I would ask that you elaborate on this point. - we don't have the resources to get where we want to be in a short timeframe, we are working on it but meanwhile we are impacting users for things we don't make real use for This is patently false. There are things we want the website to do in the future, sure. That does not mean we should stop collecting data. Nearly all of the changes that affect the website happen in either the daisy codebase (the system that receives the crashes) or the errors codebase (the website itself). We are taking a big data approach to this problem and collecting more information than we are using at present. Thus, the changes we make are mostly ways to better map the flow of information to our database, Cassandra. It is often possible to back-populate the new structure with the existing data. So when a new feature to the website lands, it will immediately begin working for releases that are already very frozen, like 12.04. This was exactly the case with the per-version breakdown on individual problem pages. I challenge the notion that the website is not usable yet. Developers are using it and there's already a wealth of valuable information on it that flat out did not exist before. Where are you going to get a more accurate prioritized list of errors? Where are you going to find a version by version breakdown of where that error manifests? Where are you going to find out how often Ubuntu is crashing for end-users (not just developers) relative to the previous version? Where are you going to find the problems that do not appear in Launchpad bugs? If I was still working on the installer, I could go to the website right now, punch ubiquity into the box and instantly have a list of what I need to focus my attention on. I *wish* I had this five years ago when Launchpad already had thousands of open bugs for ubiquity. Talk to David Pitkin and the software center team. It is my understanding that they use this website extensively to prioritize work and fix major issues. I have constantly seen peaks and troughs as programming error
Minutes from the 12.04.1 team meeting (Thursday 2nd of August)
The seventh 12.04.1 team meeting took place at 14:00 UTC on Thursday the 2nd of August 2012. == Attendees == * arges * Daviey * jibel * NCommander * seb128 * skaet * smartboyhw * smoser * stgraber (chair) == Notes == === Deadlines === The upcoming deadlines are: * last Thursday 21:00 UTC: Beginning of PointReleaseProcess and DesktopInfrastructureFreeze * 2012/08/09: KernelFreeze, LanguageTranslationDeadline, SRU Fix Validation Testing * 2012/08/16: FinalFreeze, ReleaseNoteFreeze * 2012/08/23: Ubuntu 12.04.1 === Bugs === The number of targeted bugs went from 106 last week to 75! Of these 75, 32 are in fix commited state (likely waiting in -proposed) and 9 are marked in progress (waiting to be approved). So that's 34 bugs that still need fixing of which 12 aren't assigned to somebody. The full list of bugs can be found at: https://bugs.launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=49926 The list of remaining bugs to fix can be found at: http://goo.gl/RUiZe Some of these aren't assigned to someone yet: http://goo.gl/22zV2 Bugs that haven't been directly discussed and agreed on with the release team will be moved to 12.04.2 at this point. If a fix that's not in -proposed or in the queue at this point, needs to get in 12.04.1, please get in touch with seb128, skaet or stgraber. (By e-mail or #ubuntu-release on IRC). === Oversizedness === A live-build fix is currently in precise-proposed and needs testing on the builders. This should help reduce by around 2MB the size of the live medias, though up to 7MB may still need freeing. Work on this will continue this week. == Team status updates == - Server: Still no clear plan for MaaS, might see something landing this week (will required exception). - Desktop: Mostly done for .1, some bugs didn't make it but that's not the end of the world and these weren't important for the iso. nux and some other updates are still in the queue. Unity update was delayed as considered too risky for .1. The desktop team would like to see whoopsie turned off, a conversation will be started on the release mailing list. - QA: Found bug 1029531, continued doing SRU verification, found a problem with wubi image generation overwriting the quanal ones. Been sprinting all week. - PES: highbank enablement landed in -updates, armadaxp is being tested now. - Foundations: Cleaned up the bug list, eglibc update should be uploaded very soon, some verification work, uploaded ubiquity and base-files in preparation for .1. - Release: tracking the translation work, precise builds are now happening for every image taking part in .1, will now start work on the release notes. - L1: Some more work on the point release bug report. == Actions == * xnox to liase with ballons, gema and jibel w.r.t. fs/storage testing (carried) * Flavor leads participating, please verify that the images are as you expect, and start smoke testing tomorrow to make sure all the right 12.04.1 bits are in place. == Next meeting == Full meeting log is available here: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-02-14.02.log.html The next meeting will be on Thursday the 9th of August at 14:00 UTC (#ubuntu-meeting on freenode). Useful resources and the meeting agenda are available at: https://wiki.ubuntu.com/PrecisePangolin/12.04.1 -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital 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
On Mon, Aug 6, 2012 at 12:09 PM, Sebastien Bacher seb...@ubuntu.com wrote: Hey Evan, thanks for the reply! Sure thing :) That's 10 times a week, that seems very often to me yes. I would be all for fixing the issues but in reality the resources allocated to that don't allow to make strong enough progress (out of software-center that you pointer before which is lucky to have a full team dedicated to it) Sure, but as Matthew points out, these dialogs serve two purposes: 1. To let the user know what just happened. 2. To let us prioritize work effectively. They do not make promises about work getting done. If there's software that is used by a sufficient number of people to move the needle on the front page of http://errors.ubuntu.com but we do not have the resources to fix the bugs in it, then we should have conversations about dropping that application as a means of reducing the number or frequency of errors. https://wiki.ubuntu.com/ErrorTracker#When_there_are_multiple_simultaneous_errors Is there any chance that would land into the LTS? I'll push it to the top of my list and try to get it done and tested by the 16th. If we disable reporting for these issues, then we'll never know the frequency at which they're occurring or what's causing them. We'll be right back at developers having to chose between failing hard to surface an issue or partially recovering from it and never knowing its true extent or the damage it inflicts. Well, by reviewing the errors since precise a good part of the issues have been judged harmless for users (often untrapped python exceptions, issues happening at session logout or random glitches from services like oneconf which do actions on regular basis and where missing a run has no real effect). Consensus in the desktop team is that while those are bugs they are often worth not bothering users about and create a sentiment of instability where not needed. I don't see how uncaught Python exceptions are harmless. Even if they were, codifying this belief of harmlessness in a try, except, pass block is a very small patch. Can you elaborate on what's causing these applications to fail on log out? I don't see how logging out by itself invalidates the contents of an error report. What I meant there is not that the datas are not useful, is that we are collecting datas about versions we will not work on (because of the resources allocated to the stable release mostly). Also the suggestion is to turn whoopsie off only for one extra release (precise) and to keep it on on other series. Well, we will be working on these releases. There are four point releases scheduled for Ubuntu 12.04. The engineering staff assigned to these releases may grow smaller, but that will not prevent developers from uploading software to 12.04. If they do and that software causes failures that did not exist before, I want them to know about it quickly and I want the release team to know about it quickly. Even if no one is going to do anything about it, any regression should be at least acknowledged and its impact known. Turning whoopsie off for precise leaves users without an explanation when any kind of application failure occurs. It means that we cannot measure stability of 12.10 against 12.04. It completely leaves us in the dark on the state of 12.04 after the .1 release. It's really going at the messenger with a hatchet. Again the issue are: - we don't have enough people dedicated to work on the precise issues, we collect datas but don't make use of them by allocating resources to fix the issues We'll have people uploading to precise-updates long after 12.04.1 is out the door. We should be monitoring the impact of this. We will have problems that surface only after this time. - it's getting hard to use the current errors.ubuntu.com summary because you can't filter out things which got a fixed rolled out from those which don't, half of the main page are probably issues we tackled but where the fix didn't reach users, as somebody planned work I would like those out of the overview because there is not a lot my team can do there, but it doesn't prevent us to see what are the real remaining issues. This is a problem of our updates mechanism more than anything else. The numbers are real. We just do a very poor job of getting fixes in the hands of users. As mentioned, as soon as the RT 54702 lands, you will be able to see the version-by-version breakdown of an individual problem. This will happen soon. We're just working through the dependency chain for python-tastypie in lucid with builds ongoing as I type this email. I also have the aforementioned branch to grey out issues that have not occurred yet in the most recent published version. If I was still working on the installer, I could go to the website right now, punch ubiquity into the box and instantly have a list of what I need to focus my attention on. I *wish* I had this five years ago when Launchpad
Re: Disabling whoopsie by default in the 12.04.1 release
On 2 August 2012 17:31, Sebastien Bacher seb...@ubuntu.com wrote: What do people think about turning whoopsie off for 12.04.1? I strongly support turning off the error message pop-ups for Ubuntu 12.04. I run a lab where we regularly get visitors who have never knowingly used Linux on a PC before. While the popup is supposed to eventually make Ubuntu less buggy, it feels like Ubuntu is more buggy. Therefore I've disabled apport since upgrading the lab to 12.04. I was surprised when I realized that it was not considered a bug for these error reports to be kept turned on once the release was final. I also was confused that System SettingsPrivacyDiagnosticsSend error reports didn't actually stop the popups. I think deploying this post-release for the first time in an LTS will cause many average users to believe that 12.04 LTS is not very high quality and not ready for use. We want people to use Ubuntu 12.04 LTS. Constantly reminding users that 12.04 is a broken buggy operating system will likely push them to use something else. Something else could be 11.10, a different Linux distribution, or Windows. This is discouraging to those who put a lot of time and work into fixing as many bugs as possible for this release. I agree that we should keep error reporting on for 12.10 and future releases. I expect that the popups will be quite a bit less frequent/intrusive for 14.04 LTS. Jeremy -- 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
(Trying to shorter the response a bit so the email keep being readeable) Sure, but as Matthew points out, these dialogs serve two purposes: 1. To let the user know what just happened. 2. To let us prioritize work effectively. They do not make promises about work getting done. If there's software that is used by a sufficient number of people to move the needle on the front page of http://errors.ubuntu.com but we do not have the resources to fix the bugs in it, then we should have conversations about dropping that application as a means of reducing the number or frequency of errors. Your reply are mostly around the line of we should fix issues, which is fine but doesn't address the concerns there. 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. The possible way out listed so far: - turn off whoopsie - increase our involvement on bugs fixing - drop buggy softwares (not really practical in the LTS, I doubt we can drop update-manager or jockey like that) - other idea you got We need to pick one and make it happen, i.e we can't say we should fix the issues and not to do, so I would suggest that we either - allocate extra resources and focus to fix the issues on the LTS or - turn off apport (I don't think dropping software is practically possible) If we go for we allocate extra resources I would like to see a concrete plan for making it happen with an commitment on results (taking the daily count by user 1 for example) and revisiting the decision later in the cycle (before LTS .2). I don't see how uncaught Python exceptions are harmless. Even if they were, codifying this belief of harmlessness in a try, except, pass block is a very small patch. It is, yet many of those sources are unmaintained and that didn't happen in the 3 months between 12.04 and 12.04.1, we need to catch up with reality and admit that we don't keep up with issues. Can you elaborate on what's causing these applications to fail on log out? I don't see how logging out by itself invalidates the contents of an error report. Usually at some point xorg closes and the dbus session bus goes away which leads applications and services which were still running and not stopped to hit an error while trying to access dbus or the xserver which went away, since usually that happens after the session closed it's mostly noise (it wouldn't happen if we had a cgroup or something which would ensure all processes are closed when the session goes away but that's not the case at the moment) Even if no one is going to do anything about it, any regression should be at least acknowledged and its impact known. That's a low probability benefit: - not enough users run proposed to get those issues showing up on the report before they move to updates (at which point we already screwed up and let a regression in -updates which shouldn't happen) - they need to rank enough so we notice them on the report - we would need a way to spot out new issues, the current by frequency ranking doesn't tell us what issue started in a recent upload Turning whoopsie off for precise leaves users without an explanation when any kind of application failure occurs. It means that we cannot measure stability of 12.10 against 12.04. It completely leaves us in the dark on the state of 12.04 after the .1 release. It's really going at the messenger with a hatchet. That's what we have been doing for 8 years, it's not perfect but it's not the end of the world, I guess we could do it for another release? - the evolution of this number? I'm not sure what you mean by this. We have a graph on the front page that shows the average number of errors per day. In the aforementioned RT it's separated out into lines for each Ubuntu version. The current graph seems to indicate we rank around 1.45 issue/day/submitter, it only goes back to 07/31/12 though (or it would maybe go back further if selecting year in the combo was working but it seems to timeout, it returns an An error occurred while trying to load the most common problems. after a while on Loading here) ... what was the number at precise release time. Can we see how much progress we did and the look of the curve? Yes, in the aforementioned RT, you see a graph on the top of the problem page with the instance count over time. You also get the version-by-version breakdown on the problem page that I mentioned above. Ok, I guess I need to wait on the RT to be closed and to see the update to see what's changing exactly but that seems good progresses, thanks for that I suspect they care more about the errors that happen than the dialogs that they get for them. It's worth noting since you've raised Windows that other mainstream operating systems do exactly what we're doing here. When applications crash on Windows or OSX, you get a similar dialog. Right, those don't have issues happening 10 times a week though, I'm sure we will
Re: Disabling whoopsie by default in the 12.04.1 release
On Mon, Aug 6, 2012 at 6:20 AM, Matthew Paul Thomas m...@canonical.com wrote: -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. Isn't that _reported_ errors? Do you have any numbers for error popups that have been dismissed? 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. I don't run a computer lab, but I did upgrade someone's computer to Ubuntu 12.04. A few days later, I felt like a total jerk as I stepped him through disabling error popups using terminal commands. (I think he opened xterm instead of gnome-terminal, too). After that, he has been very happy with the system. It isn't that he doesn't like helping: he just doesn't want to be bothered about it, at random, by some popup that reads like the sky is falling. He has work to do, and he likes to focus on it rather than his computer. That's why he switched to Ubuntu a few years ago. -- Dylan 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 ;) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
