Hello John,
I'd like to follow up on IRC conversation we had during "Android Common Tree & Upstreaming" at LDS https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-o-android
May 11 10:49:08 <pfalcon> jstultz_vm: what about "continuous merging" of linaro tree with android patches (that's exactly why I asked about maintaining a separate patch ;-) ) May 11 10:49:46 <jstultz_vm> pfalcon: so i can do that, but part of it is the time required to validate that the combination didn't break anything. May 11 10:49:52 <jstultz_vm> (which has happened in the past) May 11 10:50:06 <jstultz_vm> that load causes me to not update constantly.. May 11 10:50:58 <jstultz_vm> i could just update it every week/few days. but i'm hesitant to push out a tree that breaks folks.
I agree that no immediate changes to the process should be done, we should get 11.05 release out, hopefully with fixes for known regressions or missing features.
I'm just trying to wrap my mind on how we'll bootstrap Continuous Integration in the next cycle, which is not far away. So, I just would like to make sure that all teams involved are on the same line to make CI work effectively, i.e. that kernel team is able to update Android kernel regularly, infrastructure team has build system which produces Android images reliably, and validation team has all hooks needed to start testing them as soon as they are built.
So, I guess validation team would lead on CI start-up sequence, when they have all needed infrastructure and testsuites integrated. In particular, I'm waiting from them for details on how build notifications should be communicated to the LAVA system.
On Mon, 2011-05-16 at 20:23 +0300, Paul Sokolovsky wrote:
I'm just trying to wrap my mind on how we'll bootstrap Continuous Integration in the next cycle, which is not far away. So, I just would like to make sure that all teams involved are on the same line to make CI work effectively, i.e. that kernel team is able to update Android kernel regularly, infrastructure team has build system which produces Android images reliably, and validation team has all hooks needed to start testing them as soon as they are built.
So bootstrapping wise from the kernel's perspective, it seems like using the linaro-android-2.6.38 tree to start would be fine. As soon as Nico opens the 2.6.39 tree, I'll work to get a linaro-android-2.6.39 tree available, and you can update your fetching scripts to pull from the new branch.
From that point, I think we just need to sort out the communication
paths. I can try to update the linaro-android tree at a fairly regular pace (I'm thinking weekly?) with more frequent updates on demand, should something like a fix be needed from Nico's tree. If there is a more specific frequency you'd like to see, please let me know.
For the last cycle I've been somewhat slow at times, as it wasn't always clear that my work (merging, resolving collisions, initial testing) was getting used. This was mostly just starting pains as the platform build process was being worked out. But it helps motivate me to update more regularly if I can get some feedback as to how the last update performed in testing. As updating a tree multiple times without anyone pulling makes it seem like unnecessary extra effort.
So, I guess validation team would lead on CI start-up sequence, when they have all needed infrastructure and testsuites integrated. In particular, I'm waiting from them for details on how build notifications should be communicated to the LAVA system.
Do keep me updated!
thanks -john
Thanks for starting this topic Paul.
As we role out Gerrit CI we'll need to host all the components of the Android build in Gerrit. Users will push their changes to Gerrit and the changes will automatically get tested and merged after review.
It works pretty good once it all gets going.
As for the upstream.
We'll get the opportunity to work with the Gerrit folks to add an upstream path to the tool. I have a flow chart in a slide from the public plan review:
https://wiki.linaro.org/Cycles/1111/PublicPlanReview?action=AttachFile&d...
Slide:
Linaro CI Loop
-Zach
On 16 May 2011 14:11, John Stultz john.stultz@linaro.org wrote:
On Mon, 2011-05-16 at 20:23 +0300, Paul Sokolovsky wrote:
I'm just trying to wrap my mind on how we'll bootstrap Continuous Integration in the next cycle, which is not far away. So, I just would like to make sure that all teams involved are on the same line to make CI work effectively, i.e. that kernel team is able to update Android kernel regularly, infrastructure team has build system which produces Android images reliably, and validation team has all hooks needed to start testing them as soon as they are built.
So bootstrapping wise from the kernel's perspective, it seems like using the linaro-android-2.6.38 tree to start would be fine. As soon as Nico opens the 2.6.39 tree, I'll work to get a linaro-android-2.6.39 tree available, and you can update your fetching scripts to pull from the new branch.
From that point, I think we just need to sort out the communication paths. I can try to update the linaro-android tree at a fairly regular pace (I'm thinking weekly?) with more frequent updates on demand, should something like a fix be needed from Nico's tree. If there is a more specific frequency you'd like to see, please let me know.
For the last cycle I've been somewhat slow at times, as it wasn't always clear that my work (merging, resolving collisions, initial testing) was getting used. This was mostly just starting pains as the platform build process was being worked out. But it helps motivate me to update more regularly if I can get some feedback as to how the last update performed in testing. As updating a tree multiple times without anyone pulling makes it seem like unnecessary extra effort.
So, I guess validation team would lead on CI start-up sequence, when they have all needed infrastructure and testsuites integrated. In particular, I'm waiting from them for details on how build notifications should be communicated to the LAVA system.
Do keep me updated!
thanks -john
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-
John Stultz -
Paul Sokolovsky -
Zach Pfeffer