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

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > 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.
>> 
>> Except when it isn't, like in "x-origin".
>> 
>> > 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.
>> 
>> I'm not sure there's disagreement.  Quoting myself:
>> 
>>     The "x-" can remind humans "this is unstable" better than a feature
>>     flag can (for machines, it's the other way round).
>> 
>> CLI and HMP are for humans.  We continue to use "x-" there.
>> 
>> QMP is for machines.  The feature flag is the sole source of truth.
>> Additional use of "x-" is fine, but not required.
>
> I guess we have different defintions of "for humans" in this context.
> I consider QMP  data still relevant for humans, because humans are
> reviewing patches to libvirt that add usage of QMP features, or

There's a much more reliable way:

1. Require tests

2. Run them with -compat unstable-input=reject,unstable-output=hide

   Or unstable-input=crash if you don't trust or don't want to rely on
   your test harness.

> triaging bug reports that include examples of usage,

Here you can run the reproducer with -compat.

>                                                      and in both
> cases it is pretty relevant to make unstable features stand out to
> the human via the x- prefix IMHO.

Your point remains at least somewhat valid all the same.