I agree this is very low prio and I do not see the need of it yet. We should focus on make the lava dashbard more useful for the end users by improving the lava-dashboard UI.
/Chi Thu On 30 March 2012 02:41, Zygmunt Krynicki <[email protected]> wrote: > W dniu 30.03.2012 02:00, Michael Hudson-Doyle pisze: >> On Thu, 29 Mar 2012 10:49:21 +0200, Zygmunt Krynicki >> <[email protected]> wrote: >>> W dniu 29.03.2012 06:36, Michael Hudson-Doyle pisze: >>>> On Tue, 27 Mar 2012 23:10:37 +0200, Zygmunt Krynicki >>>> <[email protected]> wrote: >>>>> Hi. >>>>> >>>>> Another specification for the backlog and your feedback. Please read >>>>> this as I'd like to move towards planning dependency blueprints (even if >>>>> they also end up in a backlog). >>>>> >>>>> https://blueprints.launchpad.net/linaro-python-dashboard-bundle/+spec/pluggable-bundle-format >>>> >>>> Hi, >>>> >>>> Can you motivate this one a bit? It seems sort of vaguely reasonable >>>> (although I feel the creeping horrors of SGML and DTDs and things on the >>>> horizon), but I would like to know the problem you are solving here. >>> >>> I actually wanted to avoid SGML that feels to be slowly creeping in. The >>> motivation is to allow the core format to remain small and lean and to >>> allow users to experiment with custom data sets. For example, if I want >>> to include accurate kernel data it could go into a linux-specific >>> section. If I want to include apt/dpkg data it could go into a >>> dpkg-specific section. Likewise if I want to include some trace / >>> profiler data specific to my application I could create my own >>> representation and store the data there. >>> >>> This goes hand in hand with plugs support in lava-test. I'd like to be >>> able to say, run that test and capture this side band data with plugs A, >>> B and C. Some ideas are: sampling CPU, memory, network and IO load, >>> capturing GPU performance data, power measurement data. Capturing >>> package data for non-apt systems. >> >> I like the idea in general, although I can't convince myself it's a >> priority. > > It's not, it's pretty low now. I just need an excuse to release a new > format with this big empty "plugs" dictionary that does not have > additionalProperties: false. > >> I'm also not sure how some details will work in practice, like how would >> the data associated with a plug be stored in postgres? Also >> experimentation sort of implies versioning, would you have a version for >> a plug, or would the diplay of older data sometimes break when you >> install a new version of a plug? > > So you are right and the only solution is, we don't. We'll keep the raw > data as it was provided. Specialized extensions can track any > deserialized / denormalized / normalized models of that data. As for > versions, we keep our current policy, every third party extension can do > whatever the author desires, including shooting themselves in the foot > if they want. > > We'll give people a sandbox to play in, I hope. > > ZK > > PS: CC-ing the list again > > -- > Zygmunt Krynicki > Linaro Validation Team > > _______________________________________________ > linaro-validation mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/linaro-validation _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
