[libvirt] [PATCH 00/44] Require QEMU 1.3.0 or newer

Tue Apr 3 15:04:03 UTC 2018

On Tue, Apr 03, 2018 at 10:57:44AM -0400, John Ferlan wrote:
> 
> 
> On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
> >> Looking at git history and considering adjustments to the VERSION file
> >> in the QEMU tree, I get:
> > 
> > IMHO targetting QEMU specifically is wrong, because the same question comes
> > up repeatedly for every piece of 3rd party software we depend on. eg it makes
> > no sense to drop support for QEMU in RHEL-6, but then keep support for yajl
> > library due to jansson being missing in RHEL-6. We need to consider host
> > OS platforms as targets, and having decided which host OS we want, that in
> > turn trivially tells us when we can raise min version of *any* software
> > package we use.
> > 
> 
> Right - but beyond depending on you to know the history, culling some
> spec file for dependencies, or trying to read/understand the
> mappings.yaml file in the CI system, it sure would be nice to have in
> some sort of tabular form what we depend on, when we first started
> depending on it, when we "discovered" that something new was replacing
> it, etc. Personally there's way too many variables and considerations to
> keep track of in my head in order to make reasonable conclusions!

Yes, its a bit rubbish that we've never documented any of this
before, so I sent a docs patch to set out a policy we could
follow. It would make it easier to identify whether it is
reasonable to cull a platform / target.

> I understand QEMU is just but one variable in the complex equation.
> Listing QEMU was just an example for this series based on the 8 years
> since 0.12 which is the minimum we support now vs. 5 years since 1.3
> which is where this series was headed. Using the 2-3 years you responded
> in other threads would bring us to QEMU 2.2 or even 2.5.

Not sure how you get to 2.2 ?  Even if we drop RHEL-6, RHEL-7 ships 1.5.3
version of QEMU.

> In the long run, I think this becomes more about being proactive than
> reactive. What will be "the policy" going forward.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|