Re: [PATCH 4/4] qapi: introduce CONFIG_READ event

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote:
> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote:
> > > x- seems safer for management tool that doesn't know about "unstable" properties..
> > 
> > Easy, traditional, and unreliable :)
> 
> > > But on the other hand, changing from x- to no-prefix is already
> > > done when the feature is stable, and thouse who use it already
> > > use the latest version of interface, so, removing the prefix is
> > > just extra work.
> > 
> > Exactly.
> > 
> 
> I think "x-" is still better for command line use of properties - we
> don't have an API to mark things unstable there, do we?

Personally I like to see "x-" prefix present *everywhere* there is
an unstable feature, and consider the need to rename when declaring
it stable to be good thing as it sets an easily identifiable line
in the sand and is self-evident to outside observers.

The self-documenting nature of the "x-" prefer is what makes it most
compelling to me. A patch submission, or command line invokation or
an example QMP command, or a bug report, that exhibit an 'x-' prefix
are an immediate red flag to anyone who sees them.

If someone sees a QMP comamnd / a typical giant QEMU command line,
they are never going to go look at the QAPI schema to check whether
any feature used had an 'unstable' marker. The 'unstable' marker
might as well not exist in most cases.

IOW, having the 'unstable' flag in the QAPI schema is great for machine
introspection, but it isn't a substitute for having an 'x-' prefix used
for the benefit of humans IMHO.

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