I think you're advocating this: - Disable the flags we can't support - Leave the flags in chromium/debug builds
I can live with that too. And, as you point out, it's easier. Mike On Mon, Mar 2, 2009 at 6:16 PM, John Abd-El-Malek <[email protected]> wrote: > The point I was trying to make was that this isn't just about crash dumps. > For example, engineering effort will have to be done to filter them out of > UMA statistics. Also, there are reentrancy issues with plugins as Darin > mentioned. We know of them, but haven't bothered spending time chasing them > down since we considered -in-process-plugins to be just a testing mode, not > one used by users. > I really don't think we want to support this kind of mode (single-process > or in-process-plugins). If we do, then we will have to make sure all of our > tests exercise this code (which we're not even close to). Until that point, > I think it's doesn't serve our users to give (and autoupdate) builds that > we're not testing. > > I'm not saying it's not possible to do this, just the opportunity cost is > not worth it. > > If anywhere near 50% of users started using whacky flags because of bugs in > our code, we have major problems, and we should be fixing them instead of > spending time supporting multiple modes. > > > On Mon, Mar 2, 2009 at 5:52 PM, Mike Belshe <[email protected]> wrote: > >> I don't think it is so black and white. If we're going to ignore all >> crash dumps that have certain cmdline flags anyway, then collecting dumps is >> not interesting. >> >> The problem is that if 50% of our userbase ends up using some whacky flag >> that causes crashes, and we don't collect the data, we could be blind to it. >> I don't think this is a realistic scenario, but I can't stay it is >> impossible either. >> >> What I do believe is: >> a) We should figure out the configurations we "support". >> b) If we're not going to support a particular configuration, we should >> let the user know. >> c) If we're not going to support a particular configuration, it needs to >> be SUPER OBVIOUS in the crash dump that the configuration was an unsupported >> one, so that we don't waste time on the bug. >> >> Proposal: >> a) Put up the warning message on startup "unsupported command line >> flags", as Darin suggests. >> b) find a way to make go/crash generally filter out crashes which >> contain dangerous cmdline flags that we don't wish to debug. >> c) figure out a way to avoid having crashers for unsupported configs >> from going to microsoft. >> >> Mike >> >> >> >> >> >> On Mon, Mar 2, 2009 at 4:55 PM, Peter Kasting <[email protected]>wrote: >> >>> On Mon, Mar 2, 2009 at 4:53 PM, Mike Belshe <[email protected]> wrote: >>> >>>> Maybe turn of crash reporting when these flags are enabled? >>> >>> >>> No, this just makes life better for us, not for users. >>> >>> PK >>> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
