From IRC earlier:
<liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:(
<asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems
I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?
Andy Doan andy.doan@linaro.org writes:
From IRC earlier:
<liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:(
<asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems
I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?
lava-android-test is a server side component just like lava-server or lava-dashboard or anything else. I'm pretty opposed to deploying it in a different way than the other bits! We talked yesterday about how we should be deploying more things from branches, but I still think there should be a human in the loop between trunk and deployment especially with the almost total lack of pre-merge testing we have today...
Cheers, mwh
On Thu, Jun 14, 2012 at 9:59 PM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Andy Doan andy.doan@linaro.org writes:
From IRC earlier:
<liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:(
<asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems
I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?
lava-android-test is a server side component just like lava-server or lava-dashboard or anything else. I'm pretty opposed to deploying it in a different way than the other bits! We talked yesterday about how we should be deploying more things from branches, but I still think there should be a human in the loop between trunk and deployment especially with the almost total lack of pre-merge testing we have today...
I am with you on having a consistent solution for server components ... the problem here really seems to be that it's a) the server component, b) the test framework and c) the repository for the tests in one bzr branch.
While I believe having a premerge testing and roll out step for a) and b), I feel that for c) this is less important and I would very much like to cut down a packaging/roll out step for each and every test I am writing/touching.
Alexander Sack asac@linaro.org writes:
On Thu, Jun 14, 2012 at 9:59 PM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Andy Doan andy.doan@linaro.org writes:
From IRC earlier:
<liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:(
<asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems
I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?
lava-android-test is a server side component just like lava-server or lava-dashboard or anything else. I'm pretty opposed to deploying it in a different way than the other bits! We talked yesterday about how we should be deploying more things from branches, but I still think there should be a human in the loop between trunk and deployment especially with the almost total lack of pre-merge testing we have today...
I am with you on having a consistent solution for server components ... the problem here really seems to be that it's a) the server component, b) the test framework and c) the repository for the tests in one bzr branch.
While I believe having a premerge testing and roll out step for a) and b), I feel that for c) this is less important and I would very much like to cut down a packaging/roll out step for each and every test I am writing/touching.
Ah right. Yes, this makes sense to me. I think this is sort of what the thread "2012.05 planning: Move existing test defintions away from LAVA test to a dedicated project" is talking about, isn't it?
Cheers, mwh
On 15 June 2012 07:54, Michael Hudson-Doyle michael.hudson@linaro.orgwrote:
Alexander Sack asac@linaro.org writes:
On Thu, Jun 14, 2012 at 9:59 PM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Andy Doan andy.doan@linaro.org writes:
From IRC earlier:
<liuyq> asac, :( it will not work now, the branches has not been deployed. Also I haven't merged yet:(
<asac> liuyq: we have to always deployt? thought we always pull latest from bzr <asac> we should always have access to all the latest tests without another deploy step <asac> doanac: ^^ new requirement it seems
I wanted to discuss here and make sure I'm clear. We basically need to stop using the lava-android-test published to pip and start always pulling lava-android-test from trunk?
lava-android-test is a server side component just like lava-server or lava-dashboard or anything else. I'm pretty opposed to deploying it in a different way than the other bits! We talked yesterday about how we should be deploying more things from branches, but I still think there should be a human in the loop between trunk and deployment especially with the almost total lack of pre-merge testing we have today...
I am with you on having a consistent solution for server components ... the problem here really seems to be that it's a) the server component, b) the test framework and c) the repository for the tests in one bzr branch.
While I believe having a premerge testing and roll out step for a) and b), I feel that for c) this is less important and I would very much like to cut down a packaging/roll out step for each and every test I am writing/touching.
Ah right. Yes, this makes sense to me. I think this is sort of what the thread "2012.05 planning: Move existing test defintions away from LAVA test to a dedicated project" is talking about, isn't it?
Yes, I think so. Actually, I guess we need a test/testcase management system(list/store/create test), and the component(lava-android-test/lava-test/...) of lava just can get the test from there and run them on lava.
Thanks, Yongqin Liu
linaro-validation@lists.linaro.org