[Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth]

We don't want to carry along old machine types forever. If we are able to
remove the pc machines up to 0.13 one day for example, this would allow
us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
BARs directly to low memory). So let's start with a deprecation message
for the old 0.xx machine types so that the (hopefully) few users of these
old systems start switching over to newer machine types instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Note: I've decided to print the warning for all pc-0.* machine types,
 but that of course doesn't mean that we also have to remove them all at
 once when we decide to finally really remove some. We could then also
 start by removing 0.10 and 0.11 only, for example (since there should
 really be no users left for these), or only up to 0.13 (to be able to
 kill rombar=0), as discussed in the "Deprecating old machine types"
 mail thread recently.

 hw/i386/pc_piix.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9f102aa..16e2fb7 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -38,6 +38,7 @@
 #include "sysemu/kvm.h"
 #include "hw/kvm/clock.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/qtest.h"
 #include "hw/sysbus.h"
 #include "sysemu/arch_init.h"
 #include "sysemu/block-backend.h"
@@ -85,6 +86,12 @@ static void pc_init1(MachineState *machine,
     MemoryRegion *rom_memory;
     ram_addr_t lowmem;
 
+    if (!qtest_enabled() && !strncmp(MACHINE_CLASS(pcmc)->name, "pc-0.", 5)) {
+        error_report("Machine type '%s' is deprecated, "
+                     "please use a newer type instead",
+                     MACHINE_CLASS(pcmc)->name);
+    }
+
     /*
      * Calculate ram split, for memory below and above 4G.  It's a bit
      * complicated for backward compatibility reasons ...
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Daniel P. Berrange]

On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). So let's start with a deprecation message
> for the old 0.xx machine types so that the (hopefully) few users of these
> old systems start switching over to newer machine types instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Note: I've decided to print the warning for all pc-0.* machine types,
>  but that of course doesn't mean that we also have to remove them all at
>  once when we decide to finally really remove some. We could then also
>  start by removing 0.10 and 0.11 only, for example (since there should
>  really be no users left for these), or only up to 0.13 (to be able to
>  kill rombar=0), as discussed in the "Deprecating old machine types"
>  mail thread recently.


As a point of reference here are the release dates:

v0.10.0: Mar 2009
v0.11.0: Sep 2009
v0.12.0: Dec 2009
v0.13.0: Oct 2010
v0.14.0: Feb 2011
v0.15.0: Aug 2011
   v1.0: Dec 2011
 v1.1.0: Jun 2012
 v1.2.0: Sep 2012
 v1.3.0: Dec 2012
 v1.4.0: Feb 2013
 v1.5.0: May 2013
 v1.6.0: Aug 2013
 v1.7.0: Nov 2013
 v2.0.0: Apr 2014
 v2.1.0: Aug 2014
 v2.2.0: Dec 2014
 v2.3.0: Apr 2015
 v2.4.0: Aug 2015
 v2.5.0: Dec 2015
 v2.6.0: May 2016
 v2.7.0: Sep 2016
 v2.8.0: Dec 2016
 v2.9.0: Apr 2017

If we deprecate in this release (~Aug/Sep 2017), and kill in the next
release  (Dec 2017), that means our oldest machine type pc-1.0 is still
going to be 6 years, or 18 major releases, old. This raises some questions

  - Do we really think that we still have users with VMs that are
    stuck on a 6 year old machine type from 18 major releases ago ?

  - Is 6 years / 18 major releases going to be our cutoff point for
    machine types going forward ?

  - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
    migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
    unless someone can show automated testing results that confirm
    it is compatible.

FYI, I'm in favour of culling old machine types, but I think when we do
this it should not be a one-off ad-hoc culling.

It should be accompanied by changes to the documentation that clearly
state our official support policy for machine type lifetimes, so that
users know what to expect for future releases.

Also unless we're going to get more serious about automated testing to
validate machine type compatibility between *all* previously releases,
I think that 6 years / 18 releases is too long a time to have any
confidence in migration compatibility between versions.

IOW, I think you should be more aggressive in culling old machine types
that this patch is...

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 :|

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth]

On 10.05.2017 11:08, Daniel P. Berrange wrote:
> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
>> We don't want to carry along old machine types forever. If we are able to
>> remove the pc machines up to 0.13 one day for example, this would allow
>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>> BARs directly to low memory). So let's start with a deprecation message
>> for the old 0.xx machine types so that the (hopefully) few users of these
>> old systems start switching over to newer machine types instead.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>  Note: I've decided to print the warning for all pc-0.* machine types,
>>  but that of course doesn't mean that we also have to remove them all at
>>  once when we decide to finally really remove some. We could then also
>>  start by removing 0.10 and 0.11 only, for example (since there should
>>  really be no users left for these), or only up to 0.13 (to be able to
>>  kill rombar=0), as discussed in the "Deprecating old machine types"
>>  mail thread recently.
> 
> 
> As a point of reference here are the release dates:
> 
> v0.10.0: Mar 2009
> v0.11.0: Sep 2009
> v0.12.0: Dec 2009
> v0.13.0: Oct 2010
> v0.14.0: Feb 2011
> v0.15.0: Aug 2011
>    v1.0: Dec 2011
>  v1.1.0: Jun 2012
>  v1.2.0: Sep 2012
>  v1.3.0: Dec 2012
>  v1.4.0: Feb 2013
>  v1.5.0: May 2013
>  v1.6.0: Aug 2013
>  v1.7.0: Nov 2013
>  v2.0.0: Apr 2014
>  v2.1.0: Aug 2014
>  v2.2.0: Dec 2014
>  v2.3.0: Apr 2015
>  v2.4.0: Aug 2015
>  v2.5.0: Dec 2015
>  v2.6.0: May 2016
>  v2.7.0: Sep 2016
>  v2.8.0: Dec 2016
>  v2.9.0: Apr 2017
> 
> If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> release  (Dec 2017)

There was kind of a consensus in the last thread in march that we should
print out the deprecation message for at least two releases, so that
users have at least one release cycle to object before a feature gets
really removed.

> that means our oldest machine type pc-1.0 is still
> going to be 6 years, or 18 major releases, old. This raises some questions
> 
>   - Do we really think that we still have users with VMs that are
>     stuck on a 6 year old machine type from 18 major releases ago ?
>
>   - Is 6 years / 18 major releases going to be our cutoff point for
>     machine types going forward ?
> 
>   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
>     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
>     unless someone can show automated testing results that confirm
>     it is compatible.

See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html
... there might be still users of 0.12  and 1.0 (though I don't hope
so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so
we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2.
So starting with a deprecation warning for 0.xx sounded like a good idea
to me.

> FYI, I'm in favour of culling old machine types, but I think when we do
> this it should not be a one-off ad-hoc culling.
> 
> It should be accompanied by changes to the documentation that clearly
> state our official support policy for machine type lifetimes, so that
> users know what to expect for future releases.

Sounds like an idea, could you please propose such a patch to the
documentation?

> Also unless we're going to get more serious about automated testing to
> validate machine type compatibility between *all* previously releases,
> I think that 6 years / 18 releases is too long a time to have any
> confidence in migration compatibility between versions.

Distro vendors often offer 5 - 10 years support for certain versions of
their Linux distros, so I think we should at least support 5 years, too.

> IOW, I think you should be more aggressive in culling old machine types
> that this patch is...

Actually, I like the idea of using the major release versions for
defining the set of removal - hoping that we will do a v3.0 next year
which then would support the previous two major release versions 1.x and
2.x, but drops support for the 0.xx versions completely ...

 Thomas

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Daniel P. Berrange]

On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote:
> On 10.05.2017 11:08, Daniel P. Berrange wrote:
> > On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> >> We don't want to carry along old machine types forever. If we are able to
> >> remove the pc machines up to 0.13 one day for example, this would allow
> >> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >> BARs directly to low memory). So let's start with a deprecation message
> >> for the old 0.xx machine types so that the (hopefully) few users of these
> >> old systems start switching over to newer machine types instead.
> >>
> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >> ---
> >>  Note: I've decided to print the warning for all pc-0.* machine types,
> >>  but that of course doesn't mean that we also have to remove them all at
> >>  once when we decide to finally really remove some. We could then also
> >>  start by removing 0.10 and 0.11 only, for example (since there should
> >>  really be no users left for these), or only up to 0.13 (to be able to
> >>  kill rombar=0), as discussed in the "Deprecating old machine types"
> >>  mail thread recently.
> > 
> > 
> > As a point of reference here are the release dates:
> > 
> > v0.10.0: Mar 2009
> > v0.11.0: Sep 2009
> > v0.12.0: Dec 2009
> > v0.13.0: Oct 2010
> > v0.14.0: Feb 2011
> > v0.15.0: Aug 2011
> >    v1.0: Dec 2011
> >  v1.1.0: Jun 2012
> >  v1.2.0: Sep 2012
> >  v1.3.0: Dec 2012
> >  v1.4.0: Feb 2013
> >  v1.5.0: May 2013
> >  v1.6.0: Aug 2013
> >  v1.7.0: Nov 2013
> >  v2.0.0: Apr 2014
> >  v2.1.0: Aug 2014
> >  v2.2.0: Dec 2014
> >  v2.3.0: Apr 2015
> >  v2.4.0: Aug 2015
> >  v2.5.0: Dec 2015
> >  v2.6.0: May 2016
> >  v2.7.0: Sep 2016
> >  v2.8.0: Dec 2016
> >  v2.9.0: Apr 2017
> > 
> > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> > release  (Dec 2017)
> 
> There was kind of a consensus in the last thread in march that we should
> print out the deprecation message for at least two releases, so that
> users have at least one release cycle to object before a feature gets
> really removed.

For removal of machine types, IMHO, I don't think we should consider
objections. Just clearly document the lifecycle so people know exactly
how long they have until end-of-life, right from the moment they deploy,
and thus won't be surprised when we remove it.

> > that means our oldest machine type pc-1.0 is still
> > going to be 6 years, or 18 major releases, old. This raises some questions
> > 
> >   - Do we really think that we still have users with VMs that are
> >     stuck on a 6 year old machine type from 18 major releases ago ?
> >
> >   - Is 6 years / 18 major releases going to be our cutoff point for
> >     machine types going forward ?
> > 
> >   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
> >     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
> >     unless someone can show automated testing results that confirm
> >     it is compatible.
> 
> See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html
> ... there might be still users of 0.12  and 1.0 (though I don't hope
> so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so
> we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2.
> So starting with a deprecation warning for 0.xx sounded like a good idea
> to me.

If 1.2 and old is known to be broken we should just deprecate those
immediately now. It is pointless keeping something around that is
known broken.

> > FYI, I'm in favour of culling old machine types, but I think when we do
> > this it should not be a one-off ad-hoc culling.
> > 
> > It should be accompanied by changes to the documentation that clearly
> > state our official support policy for machine type lifetimes, so that
> > users know what to expect for future releases.
> 
> Sounds like an idea, could you please propose such a patch to the
> documentation?

Yep.

> > Also unless we're going to get more serious about automated testing to
> > validate machine type compatibility between *all* previously releases,
> > I think that 6 years / 18 releases is too long a time to have any
> > confidence in migration compatibility between versions.
> 
> Distro vendors often offer 5 - 10 years support for certain versions of
> their Linux distros, so I think we should at least support 5 years, too.

We have two distinct needs in that area.

RHEL has ignored upstream machine types & defined its own forever, so
we don't need to keep pc-xxxx machines around to help RHEL. Ubuntu has
more recently started defining custom machine types too.

If, however, we also started deleting the underlying features (rombar=0)
that RHEL needs in order to create its custom machine types, then that
would cause downstream problems. For example RHEL-7.4 with QEMU 2.9.0
tries to provide a "rhel6.0.0" machine type for compatibility with
old QEMU 0.12 version it orginally shipped.

So while we can delete pc-0.12, we can't delete associated features needed
by pc-0.12, without complicating RHEL's ability to create its back-compat
machine types. Downstream would have to un-delete the features.

> > IOW, I think you should be more aggressive in culling old machine types
> > that this patch is...
> 
> Actually, I like the idea of using the major release versions for
> defining the set of removal - hoping that we will do a v3.0 next year
> which then would support the previous two major release versions 1.x and
> 2.x, but drops support for the 0.xx versions completely ...

I think tieing removal to major versions is a mistake, unless we're
going to set a fixed timeframe for delivery of major versions. ie if
we gaurantee that we'll ship a new major version every 18 months, that
gives people a predictable lifetime.  If we carry on inventing reasons
for major versions at arbitrary points in time, it makes it difficult
to have any reasonable forward planning.  It is more users friendly if
we can set a clear fixed timeframe for machine type lifecycle / eol

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 :|

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth]

On 10.05.2017 12:31, Daniel P. Berrange wrote:
> On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote:
>> On 10.05.2017 11:08, Daniel P. Berrange wrote:
[...]
>>>   - Do we really think that we still have users with VMs that are
>>>     stuck on a 6 year old machine type from 18 major releases ago ?
>>>
>>>   - Is 6 years / 18 major releases going to be our cutoff point for
>>>     machine types going forward ?
>>>
>>>   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
>>>     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
>>>     unless someone can show automated testing results that confirm
>>>     it is compatible.
>>
>> See https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg05837.html
>> ... there might be still users of 0.12  and 1.0 (though I don't hope
>> so), and everything before QEMU 1.2 can't be (life-)migrated anymore, so
>> we can nuke 0.10 and 0.11 for sure, maybe also the others up to 1.2.
>> So starting with a deprecation warning for 0.xx sounded like a good idea
>> to me.
> 
> If 1.2 and old is known to be broken we should just deprecate those
> immediately now. It is pointless keeping something around that is
> known broken.

Thinking about this again - yeah, you're right. I'll send a v2 of my
patch that deprecates 1.0 - 1.2, too.

>>> Also unless we're going to get more serious about automated testing to
>>> validate machine type compatibility between *all* previously releases,
>>> I think that 6 years / 18 releases is too long a time to have any
>>> confidence in migration compatibility between versions.
>>
>> Distro vendors often offer 5 - 10 years support for certain versions of
>> their Linux distros, so I think we should at least support 5 years, too.
> 
> We have two distinct needs in that area.
> 
> RHEL has ignored upstream machine types & defined its own forever, so
> we don't need to keep pc-xxxx machines around to help RHEL. Ubuntu has
> more recently started defining custom machine types too.
> 
> If, however, we also started deleting the underlying features (rombar=0)
> that RHEL needs in order to create its custom machine types, then that
> would cause downstream problems. For example RHEL-7.4 with QEMU 2.9.0
> tries to provide a "rhel6.0.0" machine type for compatibility with
> old QEMU 0.12 version it orginally shipped.

But isn't the whole point of deprecating features in upstream that we
can get rid of this legacy cruft like rombar=0 ? Also, how do you
determine whether you can finally remove such a feature from the
upstream code? Go through all long-term supported distros and ask
around? I think that is not really feasible...

> So while we can delete pc-0.12, we can't delete associated features needed
> by pc-0.12, without complicating RHEL's ability to create its back-compat
> machine types. Downstream would have to un-delete the features.

So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
think removing pc-0.12, but not removing rombar=0 will cause confusion
in the upstream code base sooner or later, so I guess we should rather
keep the pc-0.12 machine until we can get rid of it together with the
rombar code. We should still mark it as deprecated, of course.

>>> IOW, I think you should be more aggressive in culling old machine types
>>> that this patch is...
>>
>> Actually, I like the idea of using the major release versions for
>> defining the set of removal - hoping that we will do a v3.0 next year
>> which then would support the previous two major release versions 1.x and
>> 2.x, but drops support for the 0.xx versions completely ...
> 
> I think tieing removal to major versions is a mistake, unless we're
> going to set a fixed timeframe for delivery of major versions. ie if
> we gaurantee that we'll ship a new major version every 18 months, that
> gives people a predictable lifetime.  If we carry on inventing reasons
> for major versions at arbitrary points in time, it makes it difficult
> to have any reasonable forward planning.  It is more users friendly if
> we can set a clear fixed timeframe for machine type lifecycle / eol

IMHO we should have a new major release after we've reached a .9 minor
release, but so far it seems like I'm the only one with that wish...

 Thomas

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). So let's start with a deprecation message
> > for the old 0.xx machine types so that the (hopefully) few users of these
> > old systems start switching over to newer machine types instead.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  Note: I've decided to print the warning for all pc-0.* machine types,
> >  but that of course doesn't mean that we also have to remove them all at
> >  once when we decide to finally really remove some. We could then also
> >  start by removing 0.10 and 0.11 only, for example (since there should
> >  really be no users left for these), or only up to 0.13 (to be able to
> >  kill rombar=0), as discussed in the "Deprecating old machine types"
> >  mail thread recently.
> 
> 
> As a point of reference here are the release dates:
> 
> v0.10.0: Mar 2009
> v0.11.0: Sep 2009
> v0.12.0: Dec 2009
> v0.13.0: Oct 2010
> v0.14.0: Feb 2011
> v0.15.0: Aug 2011
>    v1.0: Dec 2011
>  v1.1.0: Jun 2012
>  v1.2.0: Sep 2012
>  v1.3.0: Dec 2012
>  v1.4.0: Feb 2013
>  v1.5.0: May 2013
>  v1.6.0: Aug 2013
>  v1.7.0: Nov 2013
>  v2.0.0: Apr 2014
>  v2.1.0: Aug 2014
>  v2.2.0: Dec 2014
>  v2.3.0: Apr 2015
>  v2.4.0: Aug 2015
>  v2.5.0: Dec 2015
>  v2.6.0: May 2016
>  v2.7.0: Sep 2016
>  v2.8.0: Dec 2016
>  v2.9.0: Apr 2017
> 
> If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> release  (Dec 2017), that means our oldest machine type pc-1.0 is still
> going to be 6 years, or 18 major releases, old. This raises some questions
> 
>   - Do we really think that we still have users with VMs that are
>     stuck on a 6 year old machine type from 18 major releases ago ?

Our RHEL6 users are still on a 0.12 derivative.

>   - Is 6 years / 18 major releases going to be our cutoff point for
>     machine types going forward ?
> 
>   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
>     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
>     unless someone can show automated testing results that confirm
>     it is compatible.

I'll give you a manual one; I just migrated:
   /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
to
   /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444

seems to have survived.
Not exactly conclusive or heavy coverage, but it's not completely
broken.

> FYI, I'm in favour of culling old machine types, but I think when we do
> this it should not be a one-off ad-hoc culling.
> 
> It should be accompanied by changes to the documentation that clearly
> state our official support policy for machine type lifetimes, so that
> users know what to expect for future releases.
> 
> Also unless we're going to get more serious about automated testing to
> validate machine type compatibility between *all* previously releases,
> I think that 6 years / 18 releases is too long a time to have any
> confidence in migration compatibility between versions.

The problem is we don't do that much testing; I know of more subtle
things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine
type? No, but it's a question of how you choose what to kill.

> IOW, I think you should be more aggressive in culling old machine types
> that this patch is...


Dave

> 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 :|
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Daniel P. Berrange]

On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berrange@redhat.com) wrote:
> > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> > release  (Dec 2017), that means our oldest machine type pc-1.0 is still
> > going to be 6 years, or 18 major releases, old. This raises some questions
> > 
> >   - Do we really think that we still have users with VMs that are
> >     stuck on a 6 year old machine type from 18 major releases ago ?
> 
> Our RHEL6 users are still on a 0.12 derivative.

Yep, but not using upstream machine types. So we can kill machine
types without affecting RHEL-6.  The separate question is whether
we can kill the associated features that are needed for RHEL to
create its legacy machine types (eg the rombar setting mentioned)

> 
> >   - Is 6 years / 18 major releases going to be our cutoff point for
> >     machine types going forward ?
> > 
> >   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
> >     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
> >     unless someone can show automated testing results that confirm
> >     it is compatible.
> 
> I'll give you a manual one; I just migrated:
>    /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
> to
>    /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444
> 
> seems to have survived.
> Not exactly conclusive or heavy coverage, but it's not completely
> broken.
> 
> > FYI, I'm in favour of culling old machine types, but I think when we do
> > this it should not be a one-off ad-hoc culling.
> > 
> > It should be accompanied by changes to the documentation that clearly
> > state our official support policy for machine type lifetimes, so that
> > users know what to expect for future releases.
> > 
> > Also unless we're going to get more serious about automated testing to
> > validate machine type compatibility between *all* previously releases,
> > I think that 6 years / 18 releases is too long a time to have any
> > confidence in migration compatibility between versions.
> 
> The problem is we don't do that much testing; I know of more subtle
> things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine
> type? No, but it's a question of how you choose what to kill.

You know of the breaks between 2.6 & 2.7 because those are modern versions
people are using & thus getting lots of attention & analysis from yourself
and other people. Arguably it just looks worse because no one is actively
using, testing or analysing 1.0 vs 2.7.

Ideally, we would only claim to support combinations that we have active
compatibility test coverage for. We lacking right now, but for the sake
of discussion, lets assume we did have some level of automated coverage.
Then there's still the question of how far back we want to be running the
testing for. I think the latter is the more important question, as it sets
us a clear process to follow, as well as a goal to reach for testing coverage.

IOW, we should be able to set ourselves a goal / process, even if we don't
yet achieve that in terms of testing.

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 :|

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Paolo Bonzini]

On 10/05/2017 16:51, Dr. David Alan Gilbert wrote:
> I'll give you a manual one; I just migrated:
>    /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
> to
>    /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444
> 
> seems to have survived.
> Not exactly conclusive or heavy coverage, but it's not completely
> broken.

Yeah, I think resetting the VM will fail, or something like that.

Paolo

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berrange@redhat.com) wrote:
> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> > > release  (Dec 2017), that means our oldest machine type pc-1.0 is still
> > > going to be 6 years, or 18 major releases, old. This raises some questions
> > > 
> > >   - Do we really think that we still have users with VMs that are
> > >     stuck on a 6 year old machine type from 18 major releases ago ?
> > 
> > Our RHEL6 users are still on a 0.12 derivative.
> 
> Yep, but not using upstream machine types. So we can kill machine
> types without affecting RHEL-6.  The separate question is whether
> we can kill the associated features that are needed for RHEL to
> create its legacy machine types (eg the rombar setting mentioned)

Right, it just felt a bit odd to kill it off upstream if we know
of users ourselves who use old versions like that.

Also remember machine types are not just about migration compatibility;
if we kill a machine type then:
  a) The users will need to modify their libvirt xml for each VM to
change machine type
  b) That change in guest view of the machine might upset the OS
installed.

I've certainly got VMs that were installed ages ago and are still using
the XML from the old installation; so that probably means using an old
machine type on a modern QEMU.

Dave

> > 
> > >   - Is 6 years / 18 major releases going to be our cutoff point for
> > >     machine types going forward ?
> > > 
> > >   - Do we have any confidence that pc-1.0 in QEMU 2.9.0 really is
> > >     migration compatible with pc-1.0 from QEMU 1.0 ? I'm doubtful
> > >     unless someone can show automated testing results that confirm
> > >     it is compatible.
> > 
> > I'll give you a manual one; I just migrated:
> >    /opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
> > to
> >    /opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic -incoming tcp::4444
> > 
> > seems to have survived.
> > Not exactly conclusive or heavy coverage, but it's not completely
> > broken.
> > 
> > > FYI, I'm in favour of culling old machine types, but I think when we do
> > > this it should not be a one-off ad-hoc culling.
> > > 
> > > It should be accompanied by changes to the documentation that clearly
> > > state our official support policy for machine type lifetimes, so that
> > > users know what to expect for future releases.
> > > 
> > > Also unless we're going to get more serious about automated testing to
> > > validate machine type compatibility between *all* previously releases,
> > > I think that 6 years / 18 releases is too long a time to have any
> > > confidence in migration compatibility between versions.
> > 
> > The problem is we don't do that much testing; I know of more subtle
> > things that have broken between 2.6 and 2.7 - so do you kill 2.6 machine
> > type? No, but it's a question of how you choose what to kill.
> 
> You know of the breaks between 2.6 & 2.7 because those are modern versions
> people are using & thus getting lots of attention & analysis from yourself
> and other people. Arguably it just looks worse because no one is actively
> using, testing or analysing 1.0 vs 2.7.
> 
> Ideally, we would only claim to support combinations that we have active
> compatibility test coverage for. We lacking right now, but for the sake
> of discussion, lets assume we did have some level of automated coverage.
> Then there's still the question of how far back we want to be running the
> testing for. I think the latter is the more important question, as it sets
> us a clear process to follow, as well as a goal to reach for testing coverage.
> 
> IOW, we should be able to set ourselves a goal / process, even if we don't
> yet achieve that in terms of testing.
> 
> 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 :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 10.05.2017 11:08, Daniel P. Berrange wrote:
>> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
[...]
>> Also unless we're going to get more serious about automated testing to
>> validate machine type compatibility between *all* previously releases,
>> I think that 6 years / 18 releases is too long a time to have any
>> confidence in migration compatibility between versions.

Seconded.

> Distro vendors often offer 5 - 10 years support for certain versions of
> their Linux distros, so I think we should at least support 5 years, too.

Non sequitur.

Distro vendors put in serious work to keep versions working for 5 - 10
years.  We can't, and we don't.  All we do is try not to break things,
which is nice, and helps the distro vendors some, but a far cry from
anything I'd dare call "support".

Perhaps an argument could be made that us keeping to try for at least 5
years would help distro vendors enough to be worthwhile.  Maybe, but
color me skeptic.

>> IOW, I think you should be more aggressive in culling old machine types
>> that this patch is...
>
> Actually, I like the idea of using the major release versions for
> defining the set of removal - hoping that we will do a v3.0 next year
> which then would support the previous two major release versions 1.x and
> 2.x, but drops support for the 0.xx versions completely ...

I wouldn't put *that* much weight into our past version numbers.  If I
remember correctly, there was no more to 1.0 than a feeling of "this 0.x
thing is getting ridiculous".

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Paolo Bonzini]

On 10/05/2017 17:37, Markus Armbruster wrote:
> Distro vendors put in serious work to keep versions working for 5 - 10
> years.  We can't, and we don't.  All we do is try not to break things,
> which is nice, and helps the distro vendors some, but a far cry from
> anything I'd dare call "support".
> 
> Perhaps an argument could be made that us keeping to try for at least 5
> years would help distro vendors enough to be worthwhile.  Maybe, but
> color me skeptic.

It's the opposite.  Distro vendors care about it, so it is at least
plausible to have things work from 5 years back, even if we don't test it.

Of course there will be bugs and corner cases.

Paolo

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Paolo Bonzini]

On 10/05/2017 16:47, Thomas Huth wrote:
>> So while we can delete pc-0.12, we can't delete associated features needed
>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>> machine types. Downstream would have to un-delete the features.
>
> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
> think removing pc-0.12, but not removing rombar=0 will cause confusion
> in the upstream code base sooner or later,

I agree.

> so I guess we should rather
> keep the pc-0.12 machine until we can get rid of it together with the
> rombar code. We should still mark it as deprecated, of course.
>
>> I think tieing removal to major versions is a mistake, unless we're
>> going to set a fixed timeframe for delivery of major versions. ie if
>> we gaurantee that we'll ship a new major version every 18 months, that
>> gives people a predictable lifetime.  If we carry on inventing reasons
>> for major versions at arbitrary points in time, it makes it difficult
>> to have any reasonable forward planning.  It is more users friendly if
>> we can set a clear fixed timeframe for machine type lifecycle / eol
>
> IMHO we should have a new major release after we've reached a .9 minor
> release, but so far it seems like I'm the only one with that wish...

I actually like that, but then you've pretty much guaranteed that you
_cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
disagreeing as heavily as it seems, I think.

Paolo

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
> > On 10.05.2017 11:08, Daniel P. Berrange wrote:
> >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> [...]
> >> Also unless we're going to get more serious about automated testing to
> >> validate machine type compatibility between *all* previously releases,
> >> I think that 6 years / 18 releases is too long a time to have any
> >> confidence in migration compatibility between versions.
> 
> Seconded.
> 
> > Distro vendors often offer 5 - 10 years support for certain versions of
> > their Linux distros, so I think we should at least support 5 years, too.
> 
> Non sequitur.
> 
> Distro vendors put in serious work to keep versions working for 5 - 10
> years.  We can't, and we don't.  All we do is try not to break things,
> which is nice, and helps the distro vendors some, but a far cry from
> anything I'd dare call "support".
> 
> Perhaps an argument could be made that us keeping to try for at least 5
> years would help distro vendors enough to be worthwhile.  Maybe, but
> color me skeptic.

Since I'm often the one having to fix the breakages when we find they've
diverged, I would prefer us to try to keep them working upstream.
Every time something slips through upstream it's more work for me.

Dave

> >> IOW, I think you should be more aggressive in culling old machine types
> >> that this patch is...
> >
> > Actually, I like the idea of using the major release versions for
> > defining the set of removal - hoping that we will do a v3.0 next year
> > which then would support the previous two major release versions 1.x and
> > 2.x, but drops support for the 0.xx versions completely ...
> 
> I wouldn't put *that* much weight into our past version numbers.  If I
> remember correctly, there was no more to 1.0 than a feeling of "this 0.x
> thing is getting ridiculous".
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 10/05/2017 16:47, Thomas Huth wrote:
>>> So while we can delete pc-0.12, we can't delete associated features needed
>>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>>> machine types. Downstream would have to un-delete the features.
>>
>> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
>> think removing pc-0.12, but not removing rombar=0 will cause confusion
>> in the upstream code base sooner or later,
>
> I agree.
>
>> so I guess we should rather
>> keep the pc-0.12 machine until we can get rid of it together with the
>> rombar code. We should still mark it as deprecated, of course.
>>
>>> I think tieing removal to major versions is a mistake, unless we're
>>> going to set a fixed timeframe for delivery of major versions. ie if
>>> we gaurantee that we'll ship a new major version every 18 months, that
>>> gives people a predictable lifetime.  If we carry on inventing reasons
>>> for major versions at arbitrary points in time, it makes it difficult
>>> to have any reasonable forward planning.  It is more users friendly if
>>> we can set a clear fixed timeframe for machine type lifecycle / eol
>>
>> IMHO we should have a new major release after we've reached a .9 minor
>> release, but so far it seems like I'm the only one with that wish...
>
> I actually like that, but then you've pretty much guaranteed that you
> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
> disagreeing as heavily as it seems, I think.

Even better: drop the '.', and stop worrying about having to wait for
some arbitrary number to come up before you're allowed to do something
;)

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Markus Armbruster]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> * Markus Armbruster (armbru@redhat.com) wrote:
>> Thomas Huth <thuth@redhat.com> writes:
>> 
>> > On 10.05.2017 11:08, Daniel P. Berrange wrote:
>> >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
>> [...]
>> >> Also unless we're going to get more serious about automated testing to
>> >> validate machine type compatibility between *all* previously releases,
>> >> I think that 6 years / 18 releases is too long a time to have any
>> >> confidence in migration compatibility between versions.
>> 
>> Seconded.
>> 
>> > Distro vendors often offer 5 - 10 years support for certain versions of
>> > their Linux distros, so I think we should at least support 5 years, too.
>> 
>> Non sequitur.
>> 
>> Distro vendors put in serious work to keep versions working for 5 - 10
>> years.  We can't, and we don't.  All we do is try not to break things,
>> which is nice, and helps the distro vendors some, but a far cry from
>> anything I'd dare call "support".
>> 
>> Perhaps an argument could be made that us keeping to try for at least 5
>> years would help distro vendors enough to be worthwhile.  Maybe, but
>> color me skeptic.
>
> Since I'm often the one having to fix the breakages when we find they've
> diverged, I would prefer us to try to keep them working upstream.
> Every time something slips through upstream it's more work for me.

I figure when downstream rebases from upstream version V to V+3, then
upstream having tried not to break things for three versions back helps,
but from that fork on, the value of upstream trying diminishes sharply.

That makes me doubt the idea that upstream should try for as long as any
downstream version exists ("at least 5 years").  Until downstreams
rebase makes more sense to me.

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth]

On 11.05.2017 09:06, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 10/05/2017 16:47, Thomas Huth wrote:
>>>> So while we can delete pc-0.12, we can't delete associated features needed
>>>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>>>> machine types. Downstream would have to un-delete the features.
>>>
>>> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
>>> think removing pc-0.12, but not removing rombar=0 will cause confusion
>>> in the upstream code base sooner or later,
>>
>> I agree.
>>
>>> so I guess we should rather
>>> keep the pc-0.12 machine until we can get rid of it together with the
>>> rombar code. We should still mark it as deprecated, of course.
>>>
>>>> I think tieing removal to major versions is a mistake, unless we're
>>>> going to set a fixed timeframe for delivery of major versions. ie if
>>>> we gaurantee that we'll ship a new major version every 18 months, that
>>>> gives people a predictable lifetime.  If we carry on inventing reasons
>>>> for major versions at arbitrary points in time, it makes it difficult
>>>> to have any reasonable forward planning.  It is more users friendly if
>>>> we can set a clear fixed timeframe for machine type lifecycle / eol
>>>
>>> IMHO we should have a new major release after we've reached a .9 minor
>>> release, but so far it seems like I'm the only one with that wish...
>>
>> I actually like that, but then you've pretty much guaranteed that you
>> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
>> disagreeing as heavily as it seems, I think.
> 
> Even better: drop the '.', and stop worrying about having to wait for
> some arbitrary number to come up before you're allowed to do something
> ;)

I agree, we shouldn't limit ourselves by saying that we can only remove
things when switching to a new major release. But I still think that
also having "regular" major releases (e.g. after each .9 minor release)
could also help us to remind ourselves to do some bigger (and likely
necessary) spring-cleaning regularly.

 Thomas

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Markus Armbruster]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> * Daniel P. Berrange (berrange@redhat.com) wrote:
>> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
>> > * Daniel P. Berrange (berrange@redhat.com) wrote:
>> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
>> > > release  (Dec 2017), that means our oldest machine type pc-1.0 is still
>> > > going to be 6 years, or 18 major releases, old. This raises some questions
>> > > 
>> > >   - Do we really think that we still have users with VMs that are
>> > >     stuck on a 6 year old machine type from 18 major releases ago ?
>> > 
>> > Our RHEL6 users are still on a 0.12 derivative.
>> 
>> Yep, but not using upstream machine types. So we can kill machine
>> types without affecting RHEL-6.  The separate question is whether
>> we can kill the associated features that are needed for RHEL to
>> create its legacy machine types (eg the rombar setting mentioned)
>
> Right, it just felt a bit odd to kill it off upstream if we know
> of users ourselves who use old versions like that.
>
> Also remember machine types are not just about migration compatibility;
> if we kill a machine type then:
>   a) The users will need to modify their libvirt xml for each VM to
> change machine type

Point taken.  But if this inconvenience is unacceptable, consider an
enterprise distribution, or maybe CentOS.

>   b) That change in guest view of the machine might upset the OS
> installed.

Unlikely, unless you migrate without a reboot.  Guests almost always
adapt to minor hardware changes on reboot just fine.

> I've certainly got VMs that were installed ages ago and are still using
> the XML from the old installation; so that probably means using an old
> machine type on a modern QEMU.

Eventually, that becomes as likely to actually work as rebooting with a
newer machine type :)

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Daniel P. Berrange]

On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
> 
> 
> On 10/05/2017 16:47, Thomas Huth wrote:
> >> So while we can delete pc-0.12, we can't delete associated features needed
> >> by pc-0.12, without complicating RHEL's ability to create its back-compat
> >> machine types. Downstream would have to un-delete the features.
> >
> > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
> > think removing pc-0.12, but not removing rombar=0 will cause confusion
> > in the upstream code base sooner or later,
> 
> I agree.
> 
> > so I guess we should rather
> > keep the pc-0.12 machine until we can get rid of it together with the
> > rombar code. We should still mark it as deprecated, of course.
> >
> >> I think tieing removal to major versions is a mistake, unless we're
> >> going to set a fixed timeframe for delivery of major versions. ie if
> >> we gaurantee that we'll ship a new major version every 18 months, that
> >> gives people a predictable lifetime.  If we carry on inventing reasons
> >> for major versions at arbitrary points in time, it makes it difficult
> >> to have any reasonable forward planning.  It is more users friendly if
> >> we can set a clear fixed timeframe for machine type lifecycle / eol
> >
> > IMHO we should have a new major release after we've reached a .9 minor
> > release, but so far it seems like I'm the only one with that wish...
> 
> I actually like that, but then you've pretty much guaranteed that you
> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
> disagreeing as heavily as it seems, I think.

I don't think we should tie removal of features to version numbers. IMHO
we should just increment the first major digit on a fixed time scale,
either once a year, or whenever we get past .9.

For removal of features, IMHO, the only important thing is to give users
deprecation clear warning for 2-3  releases, and ensure feature detection
works well. As long as that is done, there shouldn't be any need to batch
them up for "major" releases. From libvirt POV, batching up removal to
major releases is not beneficial. Batching to major releases gives a very
inconsistent timeframe for removal too - somethign fdeprecated in .1
release may live on for years,  until the next $major.0, while something
deprecated in a .9 release can be killed in 4 months. I much prefer to
see a consistent deprecated for 2 releases / 8 months, then deleted
regardless of feature.

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 :|

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Markus Armbruster]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
>> 
>> 
>> On 10/05/2017 16:47, Thomas Huth wrote:
>> >> So while we can delete pc-0.12, we can't delete associated features needed
>> >> by pc-0.12, without complicating RHEL's ability to create its back-compat
>> >> machine types. Downstream would have to un-delete the features.
>> >
>> > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
>> > think removing pc-0.12, but not removing rombar=0 will cause confusion
>> > in the upstream code base sooner or later,
>> 
>> I agree.
>> 
>> > so I guess we should rather
>> > keep the pc-0.12 machine until we can get rid of it together with the
>> > rombar code. We should still mark it as deprecated, of course.
>> >
>> >> I think tieing removal to major versions is a mistake, unless we're
>> >> going to set a fixed timeframe for delivery of major versions. ie if
>> >> we gaurantee that we'll ship a new major version every 18 months, that
>> >> gives people a predictable lifetime.  If we carry on inventing reasons
>> >> for major versions at arbitrary points in time, it makes it difficult
>> >> to have any reasonable forward planning.  It is more users friendly if
>> >> we can set a clear fixed timeframe for machine type lifecycle / eol
>> >
>> > IMHO we should have a new major release after we've reached a .9 minor
>> > release, but so far it seems like I'm the only one with that wish...
>> 
>> I actually like that, but then you've pretty much guaranteed that you
>> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
>> disagreeing as heavily as it seems, I think.
>
> I don't think we should tie removal of features to version numbers. IMHO
> we should just increment the first major digit on a fixed time scale,
> either once a year, or whenever we get past .9.
>
> For removal of features, IMHO, the only important thing is to give users
> deprecation clear warning for 2-3  releases, and ensure feature detection
> works well. As long as that is done, there shouldn't be any need to batch
> them up for "major" releases. From libvirt POV, batching up removal to
> major releases is not beneficial. Batching to major releases gives a very
> inconsistent timeframe for removal too - somethign fdeprecated in .1
> release may live on for years,  until the next $major.0, while something
> deprecated in a .9 release can be killed in 4 months. I much prefer to
> see a consistent deprecated for 2 releases / 8 months, then deleted
> regardless of feature.

I concur.

Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Thomas Huth]

On 11.05.2017 17:10, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
>> On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
>>>
>>>
>>> On 10/05/2017 16:47, Thomas Huth wrote:
>>>>> So while we can delete pc-0.12, we can't delete associated features needed
>>>>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>>>>> machine types. Downstream would have to un-delete the features.
>>>>
>>>> So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
>>>> think removing pc-0.12, but not removing rombar=0 will cause confusion
>>>> in the upstream code base sooner or later,
>>>
>>> I agree.
>>>
>>>> so I guess we should rather
>>>> keep the pc-0.12 machine until we can get rid of it together with the
>>>> rombar code. We should still mark it as deprecated, of course.
>>>>
>>>>> I think tieing removal to major versions is a mistake, unless we're
>>>>> going to set a fixed timeframe for delivery of major versions. ie if
>>>>> we gaurantee that we'll ship a new major version every 18 months, that
>>>>> gives people a predictable lifetime.  If we carry on inventing reasons
>>>>> for major versions at arbitrary points in time, it makes it difficult
>>>>> to have any reasonable forward planning.  It is more users friendly if
>>>>> we can set a clear fixed timeframe for machine type lifecycle / eol
>>>>
>>>> IMHO we should have a new major release after we've reached a .9 minor
>>>> release, but so far it seems like I'm the only one with that wish...
>>>
>>> I actually like that, but then you've pretty much guaranteed that you
>>> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
>>> disagreeing as heavily as it seems, I think.
>>
>> I don't think we should tie removal of features to version numbers. IMHO
>> we should just increment the first major digit on a fixed time scale,
>> either once a year, or whenever we get past .9.

Once a year sounds too often for my personal taste, I really prefer the
.9 way, but that's details...

>> For removal of features, IMHO, the only important thing is to give users
>> deprecation clear warning for 2-3  releases, and ensure feature detection
>> works well. As long as that is done, there shouldn't be any need to batch
>> them up for "major" releases. From libvirt POV, batching up removal to
>> major releases is not beneficial. Batching to major releases gives a very
>> inconsistent timeframe for removal too - somethign fdeprecated in .1
>> release may live on for years,  until the next $major.0, while something
>> deprecated in a .9 release can be killed in 4 months. I much prefer to
>> see a consistent deprecated for 2 releases / 8 months, then deleted
>> regardless of feature.
> 
> I concur.

Fine for me, too. My only additional point is that we *should* have
major releases from time to time (ending up with something like QEMU
2.42 is just ugly), and that we *could* use them for additional
spring-cleaning (not for the libvirt POV, but for the users POV). For
example, we've got some parameters where we warn since QEMU 1.3 that it
is deprecated and might go away soon. We now could use major releases to
remind ourselves from time to time to look through the code for such
deprecated interfaces and remove them with the next major version. (But
removal would of course also be allowed at any other minor version
release if the feature has been deprecated for at least two minor
releases already).

 Thomas