Kevin Wolf <kw...@redhat.com> writes: > Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben: [...] >> Let's assume all libvirt ever does with deprecation notices is logging >> them. Would that solve the problem of reliably alerting libvirt >> developers to deprecation issues? Nope. But it could help >> occasionally. > > I'm not saying that deprecation notices would hurt, just that they > probably won't solve problem alone.
No argument. > Crashing if --future is given and logging otherwise seems reasonable > enough to me. Whether we need to wire up a new deprecation mechanism in > QMP for the logging or if we can just keep printing to stderr is > debatable. stderr already ends up in a log file, a QMP extension would > require new libvirt code. If libvirt would log deprecation notices more > prominently, or use the information for tainting or any other kind of > processing, a dedicated QMP mechanism could be justified. I'd like to start with two tasks: * A CLI option to configure what to do on use of a deprecated feature. We currently warn. We want to be able to crash instead. Silencing the warnings might be useful. Turning them into errors might be useful. The existing ad hoc warnings need to be replaced by a call of a common function that implements the configurable behavior. * QAPI feature flag "deprecated", for introspectable deprecation, and without ad hoc code. Then see whether our users need more.
