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:
<http://validation.linaro.org/lava-server/dashboard/streams/private/team/linaro/ci-linux-arm-soc-for-next/bundles/9f4c37d84baafae6e9ae7f45005b737ddeda6ec0/432b41e6-2f9c-11e2-9371-11f87cca7ad8/software-context/>
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
_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation
