* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote: > > Daniel P. Berrangé <berra...@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 > triaging bug reports that include examples of usage, and in both > cases it is pretty relevant to make unstable features stand out to > the human via the x- prefix IMHO.
Using x- for events makes sense to me; the semantics of events can be quite subtle; often you don't find out how broken they are until you wire them through libvirt and up the stack; so it's not impossible you might need to change it - but then without the x- the semantics (rather than existence) of the event is carved in stone. Dave > 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 :| > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/