W dniu 30.03.2012 02:00, Michael Hudson-Doyle pisze:
On Thu, 29 Mar 2012 10:49:21 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 29.03.2012 06:36, Michael Hudson-Doyle pisze:
On Tue, 27 Mar 2012 23:10:37 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org 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/plugga...
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
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 zygmunt.krynicki@linaro.org wrote:
W dniu 30.03.2012 02:00, Michael Hudson-Doyle pisze:
On Thu, 29 Mar 2012 10:49:21 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 29.03.2012 06:36, Michael Hudson-Doyle pisze:
On Tue, 27 Mar 2012 23:10:37 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org 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/plugga...
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 linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
linaro-validation@lists.linaro.org
-
Le.chi Thu -
Zygmunt Krynicki