On Wed, 15 Jun 2011, Peter Maydell wrote: > The underlying cause here is that QEMU's models are not > tested in any formal way against a specification or > against a test suite used for validating the hardware. > The main test is "does it boot Linux?". So it's inevitable > that new kernel features will be exercising essentially > untested QEMU code, and breakage is quite likely. > > CI will help to flag this kind of problem up sooner > (and I have a blueprint for this cycle to work with the > validation folks to expand the range of QEMU automated > testing and benchmarking), but if we want to guarantee > that QEMU and the kernel work together I think we really > need to pretty much freeze the kernel two weeks before > QEMU's release date, in order to have a fighting chance > at catching and fixing problems.
I don't think it is reasonable to freeze the kernel for two weeks in a ~4 week cycle. Therefore we might have to consider simply not having the same release dates for all components. We could pipeline the dependencies instead of being all synchronous. Nicolas _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
