On 18 February 2014 12:17, Alexander Graf <ag...@suse.de> wrote: > On 02/18/2014 12:22 PM, Peter Maydell wrote: >> My criteria for ARM in the past has typically been "there's >> a new release every three months, anything that got past >> the release testing process for release N is sufficiently >> non-critical it can just go into release N+1". > > Unfortunately this doesn't work for distributions. Distros > need to maintain a stable branch for the lifetime of a release > to ensure that we're reasonably regression free. > > If you indicate that this doesn't apply to ARM it basically means you admit > that ARM systems are not yet ready for "stable" use by customers when they > want to use KVM. At least at the point when we agree that customers do want > to run on a stable base for virtualization on ARM we need a working -stable > system for critical fixes.
I agree in general that ARM support needs to move from its traditional "this is just a dev tool" situation to a broader level of support/stability guarantees for KVM. (We're not yet guaranteeing cross-version migration, for another example there.) However again we run into the definition of "what's a critical fix?". I think if distros need a stable branch then they need to be prepared to do the work of sorting through what counts as a critical fix that needs to be ported to that branch. (For instance, which boards and targets do they care about?) For instance patch 3 only applies to the integrator board, and I don't consider the guest-to-host border to be a security boundary for most of our legacy board models: there's just too much unaudited device code for that to be trustable. thanks -- PMM
