Re: [PATCH 14/14] docs: document special exception for machine type deprecation & removal

2024-05-02 Thread Daniel P . Berrangé
On Thu, May 02, 2024 at 11:47:40AM +0200, Thomas Huth wrote:
> On 01/05/2024 20.27, Daniel P. Berrangé wrote:
> > This extends the deprecation policy to indicate that versioned machine
> > types will be marked deprecated after 3 years, and then subject to
> > removal after a further 3 years has passed.
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >   docs/about/deprecated.rst | 12 
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > index 7b8aafa15b..55120e774c 100644
> > --- a/docs/about/deprecated.rst
> > +++ b/docs/about/deprecated.rst
> > @@ -11,6 +11,18 @@ releases, the feature is liable to be removed. 
> > 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.
> > +As a special exception to this general timeframe, rather than have an
> > +indefinite lifetime, versioned machine types are only intended to be
> > +supported for a period of 6 years, equivalent to 18 QEMU releases. All
> > +versioned machine types will be automatically marked deprecated after an
> > +initial 3 years (9 QEMU releases) has passed, and will then be deleted 
> > after
> 
> Should there be the word "period" after "3 years" ? Otherwise it sounds a
> little bit weird to me - but I'm also not a native speaker, so I might be
> wrong.

It would be valid to say either  "3 year period" or "3 years", but
not "3 years period".
 
> > +a further 3 year period has passed. It is recommended that a deprecated
> > +machine type is only used for incoming migrations and restore of saved 
> > state,
> > +for pre-existing VM deployments.
> 
> Should we maybe add a sentence that they should ideally be updated to a
> newer machine type during a service window with downtime? (well, it might be
> also obvious, so maybe not worth to mention it)

Sure, I'm fine adding something about that, as it helps to steer people
in the sane direction.

> >  Newly deployed VMs should exclusively use a
> > +non-deprecated machine type, with use of the most recent version highly
> > +recommended. Non-versioned machine types follow the general feature
> > +deprecation policy.
> 
> Anyway:
> Reviewed-by: Thomas Huth 
> 

With 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: [PATCH 14/14] docs: document special exception for machine type deprecation & removal

2024-05-02 Thread Thomas Huth

On 01/05/2024 20.27, Daniel P. Berrangé wrote:

This extends the deprecation policy to indicate that versioned machine
types will be marked deprecated after 3 years, and then subject to
removal after a further 3 years has passed.

Signed-off-by: Daniel P. Berrangé 
---
  docs/about/deprecated.rst | 12 
  1 file changed, 12 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b8aafa15b..55120e774c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -11,6 +11,18 @@ releases, the feature is liable to be removed. 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.
  
+As a special exception to this general timeframe, rather than have an

+indefinite lifetime, versioned machine types are only intended to be
+supported for a period of 6 years, equivalent to 18 QEMU releases. All
+versioned machine types will be automatically marked deprecated after an
+initial 3 years (9 QEMU releases) has passed, and will then be deleted after


Should there be the word "period" after "3 years" ? Otherwise it sounds a 
little bit weird to me - but I'm also not a native speaker, so I might be wrong.



+a further 3 year period has passed. It is recommended that a deprecated
+machine type is only used for incoming migrations and restore of saved state,
+for pre-existing VM deployments.


Should we maybe add a sentence that they should ideally be updated to a 
newer machine type during a service window with downtime? (well, it might be 
also obvious, so maybe not worth to mention it)



 Newly deployed VMs should exclusively use a
+non-deprecated machine type, with use of the most recent version highly
+recommended. Non-versioned machine types follow the general feature
+deprecation policy.


Anyway:
Reviewed-by: Thomas Huth