move the discussion to the ml.
---------- Forwarded message ----------
On 09/11/2012 10:22 AM, Fathi Boudra wrote:
3.2) knowing the test source. I found this pretty interesting and did some
poking around. We have the concept of a "software context" in LAVA:
However, as it stands, we only populate it with dpkg information. Even if your core test code was a package, I've seen enough threads on going from package to source on linaro-dev that I'll assume that's useless. Within the software context we have a structure that currently unused called "software sources". I think this would enable drilling down to what you are after.
The big question is*how* we populate that information. Based on the
I think we would want to add some field where you could pass this to the Test object you create. That would be pretty simple. I'm not sure if that would be ideal which is why I added Michael to the thread.
So, just to make sure: does addressing 3.2 first make sense?
It make sense. If we want to track the test sources, we want the software context/source references feature. Now, how can we populate it (Project/VCS/branch/tag or revision)?
Here's a way we could do this in lava-test:
http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revision/173
Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?
W dniu 12.09.2012 10:23, Fathi Boudra pisze:
move the discussion to the ml.
---------- Forwarded message ----------
On 09/11/2012 10:22 AM, Fathi Boudra wrote:
3.2) knowing the test source. I found this pretty interesting and did some
poking around. We have the concept of a "software context" in LAVA:
However, as it stands, we only populate it with dpkg information. Even if your core test code was a package, I've seen enough threads on going from package to source on linaro-dev that I'll assume that's useless. Within the software context we have a structure that currently unused called "software sources". I think this would enable drilling down to what you are after.
The big question is*how* we populate that information. Based on the
I think we would want to add some field where you could pass this to the Test object you create. That would be pretty simple. I'm not sure if that would be ideal which is why I added Michael to the thread.
So, just to make sure: does addressing 3.2 first make sense?
It make sense. If we want to track the test sources, we want the software context/source references feature. Now, how can we populate it (Project/VCS/branch/tag or revision)?
Here's a way we could do this in lava-test:
http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revision/173
Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?
I'm glad someone has finally started considering using the software sources concept that was present in lava for a lot of time.
I think that putting it in lava-test is wrong. The only correct way that gives us more than 1% of coverage (in mapping from stuff running to code) is to put it in meta-data that we can observe on the machine at runtime.
Out of possible solutions:
* A new X-* header in dpkg control file (easy to scan those by reading a single 'status' file!).
* A method of special support for lava-test and similar tools, when the test pulls (and perhaps builds) something out of a git or bzr repo. There is a lot of existing code that can do this in lava-vcs. It already support git and bzr.
NOTE: I don't oppose some form of support in lava-test, in special one-off cases but it should be clear that we need a better way of discovering where stuff came from.
Thanks ZK
On 09/12/2012 05:33 AM, Zygmunt Krynicki wrote:
W dniu 12.09.2012 10:23, Fathi Boudra pisze:
move the discussion to the ml.
---------- Forwarded message ----------
On 09/11/2012 10:22 AM, Fathi Boudra wrote:
3.2) knowing the test source. I found this pretty interesting and did some
poking around. We have the concept of a "software context" in LAVA:
However, as it stands, we only populate it with dpkg information. Even if your core test code was a package, I've seen enough threads on going from package to source on linaro-dev that I'll assume that's useless. Within the software context we have a structure that currently unused called "software sources". I think this would enable drilling down to what you are after.
The big question is*how* we populate that information. Based on the
I think we would want to add some field where you could pass this to the Test object you create. That would be pretty simple. I'm not sure if that would be ideal which is why I added Michael to the thread.
So, just to make sure: does addressing 3.2 first make sense?
It make sense. If we want to track the test sources, we want the software context/source references feature. Now, how can we populate it (Project/VCS/branch/tag or revision)?
Here's a way we could do this in lava-test:
http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revision/173
Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?
I'm glad someone has finally started considering using the software sources concept that was present in lava for a lot of time.
I think that putting it in lava-test is wrong. The only correct way that gives us more than 1% of coverage (in mapping from stuff running to code) is to put it in meta-data that we can observe on the machine at runtime.
Out of possible solutions:
- A new X-* header in dpkg control file (easy to scan those by reading a
single 'status' file!).
- A method of special support for lava-test and similar tools, when the
test pulls (and perhaps builds) something out of a git or bzr repo. There is a lot of existing code that can do this in lava-vcs. It already support git and bzr.
I think my branch is sort of doing that now.
NOTE: I don't oppose some form of support in lava-test, in special one-off cases but it should be clear that we need a better way of discovering where stuff came from.
I agree it would be optimal to get over the 1% hump. However, the people that I'm working with right now only care about this 1%. So I'd like to see if we are okay with the mechanism for covering that.
Then we can argue at the next 2 Connects how to get platform support for the 99% :)
Thanks ZK
Andy wrote [quoting went funny somewhere]:
Here's a way we could do this in lava-test:
http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revision/173
Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?
Seems kind of OK. I don't think I have deep conceptual insight into the problem being solved here though :-)
Cheers, mwh
On 09/12/2012 08:39 PM, Michael Hudson-Doyle wrote:
Andy wrote [quoting went funny somewhere]:
Here's a way we could do this in lava-test:
http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revision/173
Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?
Seems kind of OK. I don't think I have deep conceptual insight into the problem being solved here though :-)
Yesterday during the LAVA team meeting, we came up with a better way to do this in code. It still doesn't cover the "99%" case, but it makes things more transparent to the test-definition. MP to follow soon.
linaro-validation@lists.linaro.org
-
Andy Doan -
Fathi Boudra -
Michael Hudson-Doyle -
Zygmunt Krynicki