Thanks Al for raising the issue. To clarify, I didn't say log switch should be "centralized" in System app. It should be centralized in Gecko.
Gaia developers are specifically told not to use |console.log/error| etc. for normal operations because it comes with performance penalty. It sounds like this ended up shoot us in the foot because of these testing needs. What I am looking at is somehow enable us to add logs in Gaia regardless, and introduce a pref in Gecko to turn them on or off. When it's turned off we should not have any performance penalty. Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Is that possible? (PS |console.log| does not comes with the right order if the code throws -- not sure if that can be fixed too.) On Thu, Aug 21, 2014 at 12:16 PM, James Lal <[email protected]> wrote: > +sicking, +jst, +paul > > So over the last few weeks I have had various discussions with people about > "logging" (there are metrics and log like data and bunch of random stuff > across gecko/gonk/gaia that fit other names too) we really badly need sane > logging data that is reachable by some single source. This is needed for a > couple of critical things: > > - debugging > - tests > - logs on other peoples phones [dogfooding builds] (another form of > debugging but you don't have the device.) > > We not only need a place to input data (in a wide reaching way) but also > nice apis for extracting that data (automation, periodic server side dumps, > crazy random new things). > > Our current situation is pretty awful (I can list the reasons but those > involved likely know what I am talking about) and we need to unify efforts > to build something better... I spoke with jst about this recently and we are > trying to find the right person to fix this. If you feel super excited/angry > about logging get in touch with one/any/all of us so we can > mentor/bribe/help you through this. > > - james > > On Wed, Aug 20, 2014 at 8:09 PM, Al Tsai <[email protected]> wrote: >> >> Hi all, >> >> I am sending this e-mail to start a discussion about current log >> mechanism. As you might know that we have different ways to collect logs, >> most kinds of logs need extra actions to enable them since performance >> issues. With more devices and users, the issues reported may not always come >> with solid STR (steps to reproduce). Some automation tests (such as MTBF and >> Orangutan Test) will not always have STR. Worse than that, the logs >> collected during testing contain no clues for resolving issues most of the >> time. >> >> Currently, the information we can get by "adb logcat" command is about >> WiFi. We'll need to use special methods to trigger RIL and it's not known by >> public. For Gaia logs, we'll need to reach the developers to know how to >> trigger its logger, or there's no logger due to performance concern. Within >> offline discuss with Tim, a centralized log mechanism control by the system >> app could be a solution. Or we can implement the log server inside gecko, >> direct all configuration to gecko, and let gecko decide when to drop logs. >> >> More thoughts are welcome. >> >> Best Regards, >> Al >> -- >> >> Al Tsai >> Senior QA Engineer, MoCo Taiwan >> Tel: +886-2-87861100 ext.358 >> >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
