Please, please make your plans include the ability to get raw text files (CSV or JSON or something else, I don't care as long as I can easily parse it). I don't have use for the current frond-end, and I believe that no front-end will cover everyone's needs, and not every developer is familiar with databases either (not even SQL) while almost everyone can easily do things with raw text files.
As a second request, please make as much data as possible public. With public data in the form of raw text files, a lot of things become possible. Thankfully we have that for crash reports ( https://crash-analysis.mozilla.com/crash_analysis/ ) and that allows me to make much more useful bugzilla comments than I otherwise could - because I can link to a public CSV file and give a Bash command (with cut|grep|wc) allowing to reproduce the result I'm claiming. Benoit 2013/2/27 Josh Aas <josh...@gmail.com> > I've been thinking about how we might improve access to telemetry data. I > don't want to get too much into the issues with the current front-end, so > suffice it to say that it isn't meeting my group's needs. > > I solicited ideas from Justin Lebar and Patrick McManus, and with those I > came up with an overview of how those of us in platform engineering would > ideally like to be able to access telemetry data. I'd love to hear thoughts > and feedback. > > === > > At the highest level, we want to make decisions, mostly regarding > optimizations, based on feedback from "the wild." We want to know when a > change makes something better or worse. We also want to be able to spot > regressions. > > The top priority for exposing telemetry data is an easy-to-use API. > Secondarily, there should be a default front-end. > > An API will allow developers to "innovate at the edges" by building tools > to fit their needs. This will also remove the one-size-fits-all requirement > from the default front-end. The API should be easier to use than mucking > with hadoop/hbase directly. It might be a RESTful JSON API. It should not > require people to apply for special privileges. > > The default front-end should be fast, stable, and flexible. It should be > based as much as possible on existing products and frameworks. Being able > to modify the display of data as needs change should be easy to do, to > avoid long wait times for new views of the data. It should provide > generally useful views of the data, breaking down results by build (builds > contain dates in their IDs), so we can see how results change from one > build to another. We want to be able to see statistical analyses such as > standard deviations, and cumulative distribution functions. > > We would also like to be able to run A/B experiments. This means coming up > with a better instrumentation framework for code in the builds, but it also > means having a dashboard that understands the results, and can show > comparisons between A and B users that otherwise have the same builds. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
