[Qemu-devel] [PATCH v5 0/2 (for 2.10] Document deprecated features & support lifecycle

[Qemu-devel] [PATCH v5 0/2 (for 2.10] Document deprecated features & support lifecycle

[Daniel P. Berrange]

This is a followup to

  v1: https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg02390.html
  v2: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01286.html
  v3: https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00651.html
  v4: https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg04239.html

I would really strongly like to see this documented in time for the
2.10 release, so that we can start the clock ticking on our deprecation
policy and thus actually delete some stuff in the not too distant
future.

The goal is to clarify to users & app developers what they can expect
from QEMU in terms of feature lifecycle & any deprecation policy should
it be neccessary to remove features.

The list of features marked as deprecated was determined by looking at
the QEMU source for the word "deprecated'. It was then compared with
the doc Thomas put up at http://wiki.qemu.org/Features/LegacyRemoval

Key differences with the wiki page that Thomas wrote up vs patch 2
in this series

 - Deprecated features are given a fixed lifespan of 2 releases,
   rather than listing deletion at a future "major" v3.0.0 release.
   This ensures that applications like libvirt have a predictable
   fixed amount of time to react to deprecations.

 - Only lists features which are currently officially deprecated,
   no list of possible future candidates. The wiki page is probably
   a good place to maintain a list of future possible deprecations.
   To turn them into actual deprecations, a patch to the QEMU doc
   can then be posted & reviewed in the normal manner.

 - Not listing the '-6' and '-e' args to qemu-img create. Those
   were never deprecations, because the functionality was
   immediately turned into a fatal error. Patches to delete these
   have been merged now

Changed in v5:

 - Removed misleading reference to "major" release (Eduardo)

Changed in v4:

 - Misc typos / wording clarification (Thomas)

Changed in v3:

 - Rename appendix to "Deprecated features" (Markus)
 - List all currently deprecated features
 - Document that deprecated features will be removed after
   2 releases of being deprecated
 - Clarify that clock for removing historically deprecated
   features starts with the forthcoming release.

Changed in v2:

 - Split into 2 patches so we can consider each suggested addition
   independantly.

Daniel P. Berrange (2):
  docs: document support lifetime for features
  docs: document deprecated features in appendix

 qemu-doc.texi | 205 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 205 insertions(+)

-- 
2.13.0

[Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features

[Daniel P. Berrange]

There is currently no explicit guidance on the duration of support
for features such as versioned machine types, which have a finite
useful lifespan. Thus apps / users cannot predict how much time
they might be able to use a feature for, before it is removed (if
ever).

This adds a new appendix that lists items which have finite lifecycles,
such as machine types. For items which are generally expected to be
supported indefinitely, it sets out the policy around deprecation
and removal, should it be needed.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
 qemu-doc.texi | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 48af5155c7..200c0f7d0a 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -38,6 +38,7 @@
 * QEMU Guest Agent::
 * QEMU User space emulator::
 * Implementation notes::
+* Support lifetime::
 * License::
 * Index::
 @end menu
@@ -3128,6 +3129,42 @@ Run the emulation in single step mode.
 
 @include qemu-tech.texi
 
+@node Support lifetime
+@appendix Support lifetime
+
+In general features are intended to be supported indefinitely once
+introduced into QEMU.
+
+In the event that a feature needs to be removed, it will be listed
+in the ``Deprecated features'' appendix of this document. The feature
+will remain functional for 2 releases prior to actual removal.
+
+Deprecated features may also generate warnings on the console when
+QEMU starts up, or if activated via a monitor command, however,
+this is not a mandatory requirement.
+
+Certain features have an inherently finite lifetime, and thus
+will be removed on a fixed schedule, without following the normal
+deprecation process. Such features are listed in the sections
+that follow.
+
+@node Machine types
+@section Machine types
+
+For architectures which aim to support live migration compatibility
+across releases, each release will introduce a new versioned machine
+type. For example, the 2.8.0 release introduced machine types
+``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
+
+To allow live migration of a guest running on a 2.8.0 release to a
+2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and
+``pc-q35-2.8''. To allow users live migrating VMs to skip multiple
+intermediate releases when upgrading, new releases of QEMU will
+support machine types from many previous versions.
+
+The supported lifetime for versioned machine types is 12 releases,
+which is equivalent to 4 years worth of previous QEMU releases.
+
 @node License
 @appendix License
 
-- 
2.13.0

[Qemu-devel] [PATCH v5 2/2 (for 2.10)] docs: document deprecated features in appendix

[Daniel P. Berrange]

The deprecation of features in QEMU is totally adhoc currently,
with no way for the user to get a list of what is deprecated
in each release. This adds an appendix to the doc that records
when each deprecation was made and provides text explaining
what to use instead, if anything.

Since there has been no formal policy around removal of deprecated
features in the past, any deprecations prior to 2.10.0 are to be
treated as if they had been made at the 2.10.0 release. Thus the
earliest that existing deprecations will be deleted is the start
of the 2.12.0 cycle.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
 qemu-doc.texi | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 200c0f7d0a..7fd01575a6 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -39,6 +39,7 @@
 * QEMU User space emulator::
 * Implementation notes::
 * Support lifetime::
+* Deprecated features::
 * License::
 * Index::
 @end menu
@@ -3165,6 +3166,173 @@ support machine types from many previous versions.
 The supported lifetime for versioned machine types is 12 releases,
 which is equivalent to 4 years worth of previous QEMU releases.
 
+@node Deprecated features
+@appendix Deprecated features
+
+The following sections provide a list of all features currently
+marked as deprecated.
+
+Prior to the 2.10.0 release there was no official policy on how
+long features would be deprecated prior to their removal, nor
+any documented list of which features were deprecated. Thus
+any features deprecated prior to 2.10.0 will be treated as if
+they were first deprecated in the 2.10.0 release.
+
+@section System emulator command line arguments
+
+@subsection -drive boot=on|off (since 1.3.0)
+
+The ``boot=on|off'' option to the ``-drive'' argument is
+ignored. Applications should use the ``bootindex=N'' parameter
+to set an absolute ordering between devices instead.
+
+@subsection -tdf (since 1.3.0)
+
+The ``-tdf'' argument is ignored. The behaviour implemented
+by this argument is now the default when using the KVM PIT,
+but can be requested explicitly using
+``-global kvm-pit.lost_tick_policy=slew''.
+
+@subsection -no-kvm-pit-reinjection (since 1.3.0)
+
+The ``-no-kvm-pit-reinjection'' argument is now a
+synonym for setting ``-global kvm-pit.lost_tick_policy=discard''.
+
+@subsection -no-kvm-irqchip (since 1.3.0)
+
+The ``-no-kvm-irqchip'' argument is now a synonym for
+setting ``-machine kernel_irqchip=off''.
+
+@subsection -no-kvm-pit (since 1.3.0)
+
+The ``-no-kvm-pit'' argument is ignored. It is no longer
+possible to disable the KVM PIT directly.
+
+@subsection -no-kvm (since 1.3.0)
+
+The ``-no-kvm'' argument is now a synonym for setting
+``-machine accel=tcg''.
+
+@subsection -monitor default=on (since 2.4.0)
+
+The ``default'' option to the ``-monitor'' argument is
+now ignored. When multiple monitors were enabled, it
+indicated which monitor would receive log messages
+from the various subsystems. This feature is no longer
+required as messages are now only sent to the monitor
+in response to explicitly monitor commands.
+
+@subsection -vnc tls (since 2.5.0)
+
+The ``-vnc tls'' argument is now a synonym for setting
+``-object tls-creds-anon,id=tls0'' combined with
+``-vnc tls-creds=tls0'
+
+@subsection -vnc x509 (since 2.5.0)
+
+The ``-vnc x509=/path/to/certs'' argument is now a
+synonym for setting
+``-object tls-creds-x509,dir=/path/to/certs,id=tls0,verify-peer=no''
+combined with ``-vnc tls-creds=tls0'
+
+@subsection -vnc x509verify (since 2.5.0)
+
+The ``-vnc x509verify=/path/to/certs'' argument is now a
+synonym for setting
+``-object tls-creds-x509,dir=/path/to/certs,id=tls0,verify-peer=yes''
+combined with ``-vnc tls-creds=tls0'
+
+@subsection -tftp (since 2.6.0)
+
+The ``-tftp /some/dir'' argument is now a synonym for setting
+the ``-netdev user,tftp=/some/dir' argument. The new syntax
+allows different settings to be provided per NIC.
+
+@subsection -bootp (since 2.6.0)
+
+The ``-bootp /some/file'' argument is now a synonym for setting
+the ``-netdev user,bootp=/some/file' argument. The new syntax
+allows different settings to be provided per NIC.
+
+@subsection -redir (since 2.6.0)
+
+The ``-redir ARGS'' argument is now a synonym for setting
+the ``-netdev user,hostfwd=ARGS'' argument instead. The new
+syntax allows different settings to be provided per NIC.
+
+@subsection -smb (since 2.6.0)
+
+The ``-smb /some/dir'' argument is now a synonym for setting
+the ``-netdev user,smb=/some/dir'' argument instead. The new
+syntax allows different settings to be provided per NIC.
+
+@subsection -net channel (since 2.6.0)
+
+The ``--net channel,ARGS'' argument is now a synonym for setting
+the ``-netdev user,guestfwd=ARGS'' argument instead.
+
+@subsection -net vlan (since 2.9.0)
+
+The ``-net van=NN'' argument is partially replaced with the
+new ``-netdev'' argument. The remaining use cases will no
+longer be directly supported in QEMU.
+
+@subsection -drive if=scsi (since 2.9.0)
+
+The ``-drive if=scsi'' argument is replaced by the the
+``-device BUS-TYPE'' argument combined with ``-drive if=none''.
+
+@subsection -net dump (since 2.10.0)
+
+The ``--net dump'' argument is now replaced with the
+``-object filter-dump'' argument which works in combination
+with the modern ``-netdev`` backends instead.
+
+@subsection -hdachs (since 2.10.0)
+
+The ``-hdachs'' argument is now a synonym for setting
+the ``cyls'', ``heads'', ``secs'', and ``trans'' properties
+on the ``ide-hd'' device using the ``-device'' argument.
+The new syntax allows different settings to be provided
+per disk.
+
+@subsection -usbdevice (since 2.10.0)
+
+The ``-usbdevice DEV'' argument is now a synonym for setting
+the ``-device usb-DEV'' argument instead. The deprecated syntax
+would automatically enable USB support on the machine type.
+If using the new syntax, USB support must be explicitly
+enabled via the ``-machine usb=on'' argument.
+
+@section qemu-img command line arguments
+
+@subsection convert -s (since 2.0.0)
+
+The ``convert -s snapshot_id_or_name'' argument is obsoleted
+by the ``convert -l snapshot_param'' argument instead.
+
+@section System emulator human monitor commands
+
+@subsection usb_add (since 2.10.0)
+
+The ``usb_add'' command is replaced by the ``device_add'' command.
+
+@subsection usb_del (since 2.10.0)
+
+The ``usb_del'' command is replaced by the ``device_del'' command.
+
+@section System emulator devices
+
+@subsection ivshmem (since 2.6.0)
+
+The ``ivshmem'' device type is replaced by either the ``ivshmem-plain''
+or ``ivshmem-doorbell`` device types.
+
+@subsection spapr-pci-vfio-host-bridge (since 2.6.0)
+
+The ``spapr-pci-vfio-host-bridge'' device type is replaced by
+the ``spapr-pci-host-bridge'' device type.
+
 @node License
 @appendix License
 
-- 
2.13.0

Re: [Qemu-devel] [PATCH v5 2/2 (for 2.10)] docs: document deprecated features in appendix

[Thomas Huth]

On 19.07.2017 12:08, Daniel P. Berrange wrote:
> The deprecation of features in QEMU is totally adhoc currently,
> with no way for the user to get a list of what is deprecated
> in each release. This adds an appendix to the doc that records
> when each deprecation was made and provides text explaining
> what to use instead, if anything.
> 
> Since there has been no formal policy around removal of deprecated
> features in the past, any deprecations prior to 2.10.0 are to be
> treated as if they had been made at the 2.10.0 release. Thus the
> earliest that existing deprecations will be deleted is the start
> of the 2.12.0 cycle.
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>  qemu-doc.texi | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features

[Thomas Huth]

On 19.07.2017 12:08, Daniel P. Berrange wrote:
> There is currently no explicit guidance on the duration of support
> for features such as versioned machine types, which have a finite
> useful lifespan. Thus apps / users cannot predict how much time
> they might be able to use a feature for, before it is removed (if
> ever).
> 
> This adds a new appendix that lists items which have finite lifecycles,
> such as machine types. For items which are generally expected to be
> supported indefinitely, it sets out the policy around deprecation
> and removal, should it be needed.
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>  qemu-doc.texi | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 48af5155c7..200c0f7d0a 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -38,6 +38,7 @@
>  * QEMU Guest Agent::
>  * QEMU User space emulator::
>  * Implementation notes::
> +* Support lifetime::
>  * License::
>  * Index::
>  @end menu
> @@ -3128,6 +3129,42 @@ Run the emulation in single step mode.
>  
>  @include qemu-tech.texi
>  
> +@node Support lifetime
> +@appendix Support lifetime
> +
> +In general features are intended to be supported indefinitely once
> +introduced into QEMU.
> +
> +In the event that a feature needs to be removed, it will be listed
> +in the ``Deprecated features'' appendix of this document. The feature
> +will remain functional for 2 releases prior to actual removal.
> +
> +Deprecated features may also generate warnings on the console when
> +QEMU starts up, or if activated via a monitor command, however,
> +this is not a mandatory requirement.

Ack for the part above.
I still think we should not auto-remove old machine types blindly, but
take a little bit more care there...

So maybe submit above part now for 2.10, to get that in and thus the
clock running, and then let's discuss the machine type part again
independently for 2.11?

 Thomas

> +Certain features have an inherently finite lifetime, and thus
> +will be removed on a fixed schedule, without following the normal
> +deprecation process. Such features are listed in the sections
> +that follow.
> +
> +@node Machine types
> +@section Machine types
> +
> +For architectures which aim to support live migration compatibility
> +across releases, each release will introduce a new versioned machine
> +type. For example, the 2.8.0 release introduced machine types
> +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> +
> +To allow live migration of a guest running on a 2.8.0 release to a
> +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and
> +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple
> +intermediate releases when upgrading, new releases of QEMU will
> +support machine types from many previous versions.
> +
> +The supported lifetime for versioned machine types is 12 releases,
> +which is equivalent to 4 years worth of previous QEMU releases.

Re: [Qemu-devel] [PATCH v5 0/2 (for 2.10] Document deprecated features & support lifecycle

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Wed, Jul 19, 2017 at 11:08:00AM +0100, Daniel P. Berrange wrote:
> This is a followup to
> 
>   v1: https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg02390.html
>   v2: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01286.html
>   v3: https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00651.html
>   v4: https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg04239.html
> 
> I would really strongly like to see this documented in time for the
> 2.10 release, so that we can start the clock ticking on our deprecation
> policy and thus actually delete some stuff in the not too distant
> future.

I agree, 2.10 material:

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features

[Paolo Bonzini]

On 19/07/2017 13:56, Thomas Huth wrote:
> +@node Machine types
> +@section Machine types
> +
> +For architectures which aim to support live migration compatibility
> +across releases, each release will introduce a new versioned machine
> +type. For example, the 2.8.0 release introduced machine types
> +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> +
> +To allow live migration of a guest running on a 2.8.0 release to a
> +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and
> +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple
> +intermediate releases when upgrading, new releases of QEMU will
> +support machine types from many previous versions.
> +
> +The supported lifetime for versioned machine types is 12 releases,
> +which is equivalent to 4 years worth of previous QEMU releases.

I think there's still no consensus on this.  The first two paragraphs
should be added to the documentation for -machine in qemu-options.hx,
since "-machine [type=]foo" is currently not documented at all.

Paolo

Re: [Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features

[Daniel P. Berrange]

On Mon, Jul 24, 2017 at 03:49:29PM +0200, Paolo Bonzini wrote:
> On 19/07/2017 13:56, Thomas Huth wrote:
> > +@node Machine types
> > +@section Machine types
> > +
> > +For architectures which aim to support live migration compatibility
> > +across releases, each release will introduce a new versioned machine
> > +type. For example, the 2.8.0 release introduced machine types
> > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> > +
> > +To allow live migration of a guest running on a 2.8.0 release to a
> > +2.9.0, the QEMU 2.9.0 version must support the ``pc-i440fx-2.8'' and
> > +``pc-q35-2.8''. To allow users live migrating VMs to skip multiple
> > +intermediate releases when upgrading, new releases of QEMU will
> > +support machine types from many previous versions.
> > +
> > +The supported lifetime for versioned machine types is 12 releases,
> > +which is equivalent to 4 years worth of previous QEMU releases.
> 
> I think there's still no consensus on this.

Indeed, which is exactly why I sent this patch - we need to come up
with a sensible policy here, so we can stop repeating the same debate
over & over & over each time some proposes a patch to kill off some
random old machine type.

The 12 release / 4 year figure was a fairly arbitrary starting
point to which I'd be hoping to see critical reviewer feedback
on (with possible counterproposals) so we can try to get something
documented, to put an end to the repeated debates in this area
each time someone proposes a patch.

>                                              The first two paragraphs
> should be added to the documentation for -machine in qemu-options.hx,
> since "-machine [type=]foo" is currently not documented at all.

I'll happily send a patch for the docs for qemu-options.hx.

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 v5 1/2 (for 2.10)] docs: document support lifetime for features

[Paolo Bonzini]

On 24/07/2017 16:11, Daniel P. Berrange wrote:
>>> +
>>> +The supported lifetime for versioned machine types is 12 releases,
>>> +which is equivalent to 4 years worth of previous QEMU releases.
>> I think there's still no consensus on this.
> 
> Indeed, which is exactly why I sent this patch - we need to come up
> with a sensible policy here, so we can stop repeating the same debate
> over & over & over each time some proposes a patch to kill off some
> random old machine type.
> 
> The 12 release / 4 year figure was a fairly arbitrary starting
> point to which I'd be hoping to see critical reviewer feedback
> on (with possible counterproposals) so we can try to get something
> documented, to put an end to the repeated debates in this area
> each time someone proposes a patch.

I agree.  At the moment, the status is "machine types never die".

We can change it, but I think that we should also make a decision on
whether removing machine types implies removing properties that only
exist for backwards-compatibility reasons.

4 year seems like a long time, but it can actually be pretty taxing for
RHEL.  I'm pretty sure that around RHEL 8.4 (some time between
2020-2022) we'll need a 1.5-ish machine type (2016).

Paolo

>>                                              The first two paragraphs
>> should be added to the documentation for -machine in qemu-options.hx,
>> since "-machine [type=]foo" is currently not documented at all.
> I'll happily send a patch for the docs for qemu-options.hx.

Re: [Qemu-devel] [PATCH v5 1/2 (for 2.10)] docs: document support lifetime for features

[Daniel P. Berrange]

On Mon, Jul 24, 2017 at 04:26:24PM +0200, Paolo Bonzini wrote:
> On 24/07/2017 16:11, Daniel P. Berrange wrote:
> >>> +
> >>> +The supported lifetime for versioned machine types is 12 releases,
> >>> +which is equivalent to 4 years worth of previous QEMU releases.
> >> I think there's still no consensus on this.
> > 
> > Indeed, which is exactly why I sent this patch - we need to come up
> > with a sensible policy here, so we can stop repeating the same debate
> > over & over & over each time some proposes a patch to kill off some
> > random old machine type.
> > 
> > The 12 release / 4 year figure was a fairly arbitrary starting
> > point to which I'd be hoping to see critical reviewer feedback
> > on (with possible counterproposals) so we can try to get something
> > documented, to put an end to the repeated debates in this area
> > each time someone proposes a patch.
> 
> I agree.  At the moment, the status is "machine types never die".
> 
> We can change it, but I think that we should also make a decision on
> whether removing machine types implies removing properties that only
> exist for backwards-compatibility reasons.
> 
> 4 year seems like a long time, but it can actually be pretty taxing for
> RHEL.  I'm pretty sure that around RHEL 8.4 (some time between
> 2020-2022) we'll need a 1.5-ish machine type (2016).

QEMU 1.5 was 2013, so that's saying RHEL 8 will want support for QEMU
machine types (and all their properties) that are ~10 years old from
upstream QEMU POV.  Possibly longer, as RHEL lifetime seems to only
ever increase

Generally I see the following choices:

 1. Upstream never removes machine types or properties they use

 2. Upstream removes machine types after N releases / Y years,
    but keeps properties related to them forever

 3. Upstream removes machine types after N releases / Y years,
    & removes some associated properties at same time.

 4. Upstream removes machine types after N releases / Y years,
    & optionally marks associated properties as deprecated,
    removing them in accordance with deprecation policy.

Option 1 is current state of play, leaving burden on upstream
forever, and letting machine list grow without bound.

Option 2 stops the '-M ?' list growing without bound, but aside from
that is the same as option 1. Not much difference from option 1, since
supporting the properties is what adds the core maint burden, not the
machine types themselves.

Options 3/4 reduce burden on QEMU upstream, at cost of requiring the
downstream vendor(s) to un-delete properties that upstream decides to
remove and deal with any fallout that entails.  The work involved in
undeleting stuff is larger than the work involved in keeping it alive
in upstream, because downstream has to undelete it, resolve conflicts,
and then do all the same work upstream would have been doing had it
not delete it & deal with further merge conflicts.


Downstreams may not care about difference betweeen option 1 & 2 if
they define their own custom machine types (RHEL & Ubuntu both do)

Effectively it comes down to who should have the maint burden,
upstream or downstream.



If it takes more work downstream to undelete & maintain machine
types in the downstream fork, that means downstream maintainers
less free time to improve QEMU upstream. From that POV, deleting
machine types & props upstream is actually counterproductive to
upstream on balance. The rational thing would thus be to stick
with status quo, and explicitly cdeclare that upstream will *never*
delete machine types, or make their lifetime long enough for the
longest lived downstream (10 years min & by the time we get to
10 years, it might even be 15 years). 


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 v5 1/2 (for 2.10)] docs: document support lifetime for features

[Paolo Bonzini]

On 24/07/2017 16:47, Daniel P. Berrange wrote:
> If it takes more work downstream to undelete & maintain machine
> types in the downstream fork, that means downstream maintainers
> less free time to improve QEMU upstream. From that POV, deleting
> machine types & props upstream is actually counterproductive to
> upstream on balance. The rational thing would thus be to stick
> with status quo, and explicitly cdeclare that upstream will *never*
> delete machine types, or make their lifetime long enough for the
> longest lived downstream (10 years min & by the time we get to
> 10 years, it might even be 15 years). 

Yeah, that makes sense.  At the moment at least Red Hat and Canonical
create custom machine types.  As soon as neither Red Hat nor Canonical
contribute to upstream QEMU, the policy can change.  But honestly, even
though I have an obvious conflict of interest, I see no reason to make
things more complicated for downstreams that are active contributors to
QEMU...

Paolo

Re: [Qemu-devel] [PATCH v5 2/2 (for 2.10)] docs: document deprecated features in appendix

[Thomas Huth]

On 19.07.2017 12:08, Daniel P. Berrange wrote:
> The deprecation of features in QEMU is totally adhoc currently,
> with no way for the user to get a list of what is deprecated
> in each release. This adds an appendix to the doc that records
> when each deprecation was made and provides text explaining
> what to use instead, if anything.
> 
> Since there has been no formal policy around removal of deprecated
> features in the past, any deprecations prior to 2.10.0 are to be
> treated as if they had been made at the 2.10.0 release. Thus the
> earliest that existing deprecations will be deleted is the start
> of the 2.12.0 cycle.
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>  qemu-doc.texi | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 168 insertions(+)
[...]
> +@subsection -monitor default=on (since 2.4.0)
> +
> +The ``default'' option to the ``-monitor'' argument is
> +now ignored. When multiple monitors were enabled, it
> +indicated which monitor would receive log messages
> +from the various subsystems. This feature is no longer
> +required as messages are now only sent to the monitor
> +in response to explicitly monitor commands.

BTW, seems like it's the "-mon" option, not the "-monitor" option that
has this "default" parameter?

 Thomas

Re: [Qemu-devel] [PATCH v5 2/2 (for 2.10)] docs: document deprecated features in appendix

[Daniel P. Berrange]

On Tue, Jul 25, 2017 at 11:35:53AM +0200, Thomas Huth wrote:
> On 19.07.2017 12:08, Daniel P. Berrange wrote:
> > The deprecation of features in QEMU is totally adhoc currently,
> > with no way for the user to get a list of what is deprecated
> > in each release. This adds an appendix to the doc that records
> > when each deprecation was made and provides text explaining
> > what to use instead, if anything.
> > 
> > Since there has been no formal policy around removal of deprecated
> > features in the past, any deprecations prior to 2.10.0 are to be
> > treated as if they had been made at the 2.10.0 release. Thus the
> > earliest that existing deprecations will be deleted is the start
> > of the 2.12.0 cycle.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> >  qemu-doc.texi | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 168 insertions(+)
> [...]
> > +@subsection -monitor default=on (since 2.4.0)
> > +
> > +The ``default'' option to the ``-monitor'' argument is
> > +now ignored. When multiple monitors were enabled, it
> > +indicated which monitor would receive log messages
> > +from the various subsystems. This feature is no longer
> > +required as messages are now only sent to the monitor
> > +in response to explicitly monitor commands.
> 
> BTW, seems like it's the "-mon" option, not the "-monitor" option that
> has this "default" parameter?

Yes, you are right.

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