+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 <at...@mozilla.com> 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 > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
