On Thu, Jul 06, 2017 at 11:41:56AM +0100, Daniel P. Berrange wrote: > On Thu, Jul 06, 2017 at 11:30:43AM +0100, Stefan Hajnoczi wrote: > > On Wed, Jul 05, 2017 at 12:07:57PM +0100, Daniel P. Berrange wrote: > > > On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote: > > > > Hi, > > > > > > > > On 05.07.2017 08:57, Chao Peng wrote: > > > > > > > > > > Q35 has been in QEMU for quite a while. Compared to the current > > > > > default > > > > > i440FX, Q35 is probably not that mature and not widely used, however > > > > > in > > > > > some case, Q35 has advantages, for example, in supporting new > > > > > features. > > > > > For instance, we have some features require PCI-e support which is > > > > > only > > > > > available on Q35 and some others need it for EFI support. It is of > > > > > course not necessary to change it as the default but if more and more > > > > > features have dependencies on Q35 because of requiring much more > > > > > modern > > > > > features then I think it may be worth to do so. In such case we can > > > > > have > > > > > more people to use it and find problems we may know or not know. > > > > > > > > Yes, IMHO at one point in time, we should switch the default machine > > > > type to q35. The i440FX is really quite old... > > > > > > > > > There are certainly some drawbacks: > > > > > - Compatibility: current code or script may need adjustment > > > > > > > > That might be a real concern ... so I think a good point in time to > > > > switch to the q35 machine type would be when we switch to the next major > > > > version number of QEMU, i.e. when we switch to version 3.0. If the users > > > > see a new major version number, they might be more willing to accept > > > > such major changes (yeah, I know, we've discussed in the past that > > > > version numbers are just numbers ... but still, there is some kind of > > > > psychological aspect to this, too, I think) > > > > > > Most users aren't even aware of version numbers of QEMU - they'll just > > > take whatever their distro has provided run it. The notion that their > > > latest distro version happened to pull in a "major" version instead of > > > previously pulling in a "minor" version is invisible to everyone, > > > except the minority of people who care about the low level details. > > > > When user-visible changes break existing setups it's common for > > packagers to ship a new family of packages that includes the major > > version number (e.g. apache2, postgresql-9.6). > > > > The last QEMU 2.x version would be considered stable and still available > > from package repos. Only critical bug and security fixes could be > > released for another, say, 2 years. > > > > This way users don't have to migrate to QEMU 3.x until they are ready. > > Given the number of security vulnerabilities packagers have to deal with > for QEMU, maintaining multiple QEMU streams in parallel is a pretty > major undertaking. I can't say that would be appealing from a Fedora > maintainer POV - it'd likely just end up shipping only the newest version > to avoid that extra maint burden. I doubt enterprise distros would ship > both versions in parallel in this way [1]. > > Even if both versions are available, the people affected by the breakage > still need to figure out that the breakage they're seeing is caused by > the change in machine type, and that installing the old version will > fix it. This is still an unpleasant experiance IMHO.
True, package naming doesn't provide an upgrade path. That will still be painful. Stefan
signature.asc
Description: PGP signature
