On 2 April 2012 06:26, Alexander Sack <[email protected]> wrote: > On Mon, Apr 2, 2012 at 3:21 AM, Zach Pfeffer <[email protected]> wrote: >> On 31 March 2012 06:43, Alexander Sack <[email protected]> wrote: >>> On Sat, Mar 31, 2012 at 10:08:27AM +0200, Le.chi Thu wrote: >>>> I found the problem. The init.rc in the ramdisk image (uInitrd) has >>>> changed. The lava-dispatcher patch the partition tables in the init.rc >>>> file. Now the partition tables have moved to the init.partitions.rc >>>> file and the init.rc import that file. >>>> >>> >>> We need to coordinate things better imo. AFAIK Zach and his team knew >>> that he was changing this file, so if he would have known that this >>> file change requires coordination with the LAVA team he probably would >>> have done that. >> >> I would have given people a heads up, but I never would have expected >> LAVA to have a dependency on an init script. > > Right. That's what I basically said, yes. If you were super brilliant > you would have remembered that we patch the partitions etc. ... but as > I said above, we need to establish a better way to track which files > are currently tightly coupled to the LAVA setup so we have a chance to > establish a process around that ... > > On top, every build after a change landing should succeed in LAVA, > especially if the previous one did ... we need to establish monitoring > the results you see and following up deeper in your teams > process/mindset. > > AFAIK you can resubmit builds manually, so establishing a policy that > stops everything if booting a tip build fail and investigating that > first, could probably be done even in the current situation.
Well we do this today - stop everything and fix things. We just do it based on our manual test results since LAVA results have not been reliable. LAVA is after all only a tool and if it doesn't work we can't let it get in the way of good process, which is stop everything and fix stuff when its broken. LAVA has come a long way, but we still have a ways to go before we can trust the results. All that said, we're all in the same platform boat so we can fix LAVA to the point we can trust it and then we can rock even harder - and then we can re-enable our premerge loop and not break the build. Woot. > > -- > Alexander Sack > Technical Director, Linaro Platform Teams > http://www.linaro.org | Open source software for ARM SoCs > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
