Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
Scott Kitterman wrote: > We'd be flooded with stacks of dupes mostly to existing bugs > and no one to triage, let alone fix them. In their current form dupes are mostly annoying, but what if the apport was redesigned so that it had a "production mode" where it only bumped a counter on the original report. Then we would be able to run queries like "which single sigsegv among all sigsegvs in all packages does users currently run into most frequently". To do this the "production mode" apport data does not have to contain core dumps with personal data, it just needs to submit a small tuple containing the parameters that we use to determine the uniqueness of a crash. An example of such a tuple could be: (HASH_OF_ELF_IMAGE, OFFSET_INTO_ELF_IMAGE_WHERE_SEGV_HAPPENED) Since Ubuntu has more bugs than developers, this type of prioritization data might be very useful. Also, on the topic of "interfering with local development"; other vendors have tried to solve this by asking "SUBMIT CRASH, DONT SUBMIT CRASH or DEBUG" whenever developer tools are installed. And SUBMIT or DONT SUBMIT whenever devs tools are not installed. Martin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
pe, 2008-11-14 kello 12:36 +0100, Martin Pitt kirjoitti: > Problem is that in order to do that, we need to catch the initial > crash first and write it to disk, i. e. we would get the CPU/IO > overhead again by default. That alone doesn't worry me too much, but > it might be an issue in certain environments. It's because of the CPU and I/O overhead that I find myself disabling apport: when I develop software on my laptop, and am debugging a segfault, it is highly frustrating to have apport take control of the machine every couple of minutes. Then I sometimes remember to put it back on. Perhaps it would be helpful for idiots like me if apport could offer to disable itself for the rest of the day, or until the next boot? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
Scott Kitterman [2008-11-14 5:46 -0500]: > I do think if there's a reasonable way to report all crashes from > -proposed, that would be a good thing. I agree. With a bit of apt-cache policy magic we can detect this on the client side. Problem is that in order to do that, we need to catch the initial crash first and write it to disk, i. e. we would get the CPU/IO overhead again by default. That alone doesn't worry me too much, but it might be an issue in certain environments. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Fri, 14 Nov 2008 09:44:00 +0100 Markus Hitter <[EMAIL PROTECTED]> wrote: > >Am 14.11.2008 um 03:25 schrieb Scott Kitterman: > >> Perhaps Apport could be taught to roll the dice and return crash >> reports in >> some fraction of cases post-release (perhaps 5 or 10 percent). >> This would >> help us catch regressions. > >I don't see a reason why Apport is automatically switched off at some >point in time. If a user is enthusiastic enough to run alpha and beta >releases (s)he already agrees to Apport's doing, so it would be >reasonable to maintain this state beyond the update to the stable >release. I find Pitti's reasons reasonably compelling. If we left it on post-release, it would be for everyone, not just people who installed pre-release. We'd be flooded with stacks of dupes mostly to existing bugs and no one to triage, let alone fix them. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Fri, 14 Nov 2008 07:51:53 + "Matthew East" <[EMAIL PROTECTED]> wrote: >On Fri, Nov 14, 2008 at 2:25 AM, Scott Kitterman <[EMAIL PROTECTED]> wrote: >> I have heard people discuss post-release regressions due to SRU/security >> updates. I was chatting with another developer last night who said he'd >> found Hardy very stable at release and less so as it got updated. >> >> Perhaps Apport could be taught to roll the dice and return crash reports in >> some fraction of cases post-release (perhaps 5 or 10 percent). This would >> help us catch regressions. > >Would enabling it in -proposed help with that? > I don't know if the installed system knows which pocket a package came from or not. I see three sources of a potentially useful density of reports post-release: 1. Regressions in -proposed/-updates. 2. Regressions from -security updates. 3. Packages used more significntly by non-developers that don't get a lot of use before release. I do think if there's a reasonable way to report all crashes from -proposed, that would be a good thing. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
Am 14.11.2008 um 03:25 schrieb Scott Kitterman: > Perhaps Apport could be taught to roll the dice and return crash > reports in > some fraction of cases post-release (perhaps 5 or 10 percent). > This would > help us catch regressions. I don't see a reason why Apport is automatically switched off at some point in time. If a user is enthusiastic enough to run alpha and beta releases (s)he already agrees to Apport's doing, so it would be reasonable to maintain this state beyond the update to the stable release. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Fri, Nov 14, 2008 at 2:25 AM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > I have heard people discuss post-release regressions due to SRU/security > updates. I was chatting with another developer last night who said he'd > found Hardy very stable at release and less so as it got updated. > > Perhaps Apport could be taught to roll the dice and return crash reports in > some fraction of cases post-release (perhaps 5 or 10 percent). This would > help us catch regressions. Would enabling it in -proposed help with that? -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apport in stable releases [was: Re: Do you really want developers to be on this list]
On Thu, 13 Nov 2008 12:48:40 +0100 Martin Pitt <[EMAIL PROTECTED]> wrote: >Markus Hitter [2008-11-13 11:56 +0100]: >> While we can't "fix" developers, we can put more automatic helpers >> into place: >> >> - Keep Apport enabled even on stable releases. Hiding bugs doesn't >> help. > >We don't disable Apport in stable releases because we want to hide >bugs. The reasons are, in descending importance: > > * core dumps potentially contain a lot of private/sensitive > information which is almost impossible to check for a casual user. > Yes, apport points out to not send a report if you did something > private, and bugs are private by default, but still.. > > * During testing the development release we already get tons of crash > reports, so we should already know (or even have fixed) the > most common crashes. The others aren't really common, and hard to > reproduce, etc., which is why we would not fix them in stable > releases *anyway* (both from an SRU policy perspective, as well as > being a manpower issue). > > * Collecting crash information and sending it to LP takes a lot of > CPU, IO, and network bandwidth, and it doesn't make sense to waste > all this, and create a sense of expectation that the crash will be > fixed in a stable release, when we know upfront that it won't. > I think these are all good reasons. I have heard people discuss post-release regressions due to SRU/security updates. I was chatting with another developer last night who said he'd found Hardy very stable at release and less so as it got updated. Perhaps Apport could be taught to roll the dice and return crash reports in some fraction of cases post-release (perhaps 5 or 10 percent). This would help us catch regressions. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Apport in stable releases [was: Re: Do you really want developers to be on this list]
Markus Hitter [2008-11-13 11:56 +0100]: > While we can't "fix" developers, we can put more automatic helpers > into place: > > - Keep Apport enabled even on stable releases. Hiding bugs doesn't > help. We don't disable Apport in stable releases because we want to hide bugs. The reasons are, in descending importance: * core dumps potentially contain a lot of private/sensitive information which is almost impossible to check for a casual user. Yes, apport points out to not send a report if you did something private, and bugs are private by default, but still.. * During testing the development release we already get tons of crash reports, so we should already know (or even have fixed) the most common crashes. The others aren't really common, and hard to reproduce, etc., which is why we would not fix them in stable releases *anyway* (both from an SRU policy perspective, as well as being a manpower issue). * Collecting crash information and sending it to LP takes a lot of CPU, IO, and network bandwidth, and it doesn't make sense to waste all this, and create a sense of expectation that the crash will be fixed in a stable release, when we know upfront that it won't. > While this doesn't fix bugs by it's self, it greatly helps to fix > them after the fact (and timely educate developers about their > practices). Right, but we have more crashes in LP than we can ever keep up with, so there's enough fodder to report to upstreams, debug, and fix. :-) > Additionally, this opens the door to get some automatic measure about > the quality of drivers or other software. Count open bugs and you > know what you roughly can expect. If you count too many of them, drop > the hardware in the compatibility list. Hardware bugs are not automatically reported. Filing bugs manually (Help -> Report a bug, or using ubuntu-bug) still works normally in stable releases. We didn't disable that, nor was it ever discussed to do so. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
