On 12.07.2017 18:12, Daniel P. Berrange wrote: > On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote: >> On 12.07.2017 17:04, Daniel P. Berrange wrote: [...] >>> I think we must document & agree on our support policy for machine >>> types, before we start marking them as deprecated. eg please consider >>> the following document before accepting this deprecation patch: >>> >>> https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html >>> >>> Note in that proposal there, I say we do *not* go through trouble of >>> explicitly marking machines as deprecated. We just document upfront >>> the intended lifecycle and then delete them when it is done. >>> >>> Just use deprecation warnings for things where there is no predictable >>> lifecycle upfront. >> >> I'm still not 100% sure whether that auto-deprecation of machine types >> is such a good idea ... since we might need to maintain machines in >> downstream a little bit longer than specified there, it might be better >> to rather deprecate them manually from time to time. > > Downstreams usually maintain custom machine types, so fact that the > upstream machine types get deleted is not a problem in itself. The problem > comes if followup internal code removal then prevents downstream from > creating their custom machine type.
Right, that's what I had in mind. > I don't think we need tie these > issues together. We can remove old machine types, without immediately > removing features that our harm creation of downstream machine types. I think that won't work. Either the required code gets removed by accident, or if not, we forget to remove it later, once downstream does not require it anymore. I think it is better to remove machine types and the related features code in the upstream code base in one shot. So manually deprecating machine types and carefully removing them later sounds like the better approach to me. > FWIW, I think your proposals have been very useful in general. It has > been way overdue to have this kind of discussion. I just want us to > focus on defining a policy, rather than making adhoc decisions each > time around, as the later is rather unpredictable for users of qemu. Well, I think your doc updates are also a very good idea, but we could simply state that we keep the old machine types around for *at least* x releases or y years. That should give users the same safety as when we're declaring that old machine types will definitely be removed after x releases or y years. Thomas
