On Tue, 2018-04-03 at 09:29 -0400, John Ferlan wrote: > Maybe we need to formulate some sort of "annual processing" to declare > minimal version support and declare certain non-maintained drivers to be > dead. I believe it becomes harder and harder to support a policy of must > keep support for some sort of "older distro" as time goes on. Tools we > use or rely on don't seem to have this same policy. Considering the > recent python-2 to python-3 adjustments and what seems to be progressing > towards a debate about JSON or yajl parse/formatting support - it seems > upstream libvirt gets caught in the middle of a many "hard places". I think there's a distinction to be made between what's part of the "base system" and what's part of the virtualization stack. The former is much harder to replace: if we want libvirt to build at all on RHEL 6, we can't use glibc features that are not available in RHEL 6's glibc, for example. Same goes for Python, yajl and many more projects we build upon. On the other hand, as long as both libvirt and QEMU can be built and run on RHEL 6, it's perfectly reasonable for someone to take the latest upstream version of *both* and run them on top of what's still a supported OS. Of course, it's still very possible to just stick with whatever your vendor is offering: in RHEL 6's case, that would be QEMU 0.12 and libvirt 0.10.2, both of which are many years old at this point. The only issue arises when you try to *combine* the two approaches, and want to have the very latest libvirt drive RHEL 6's ancient QEMU version. That's the kind of scenario that, when acknowledged, forces us to keep around a lot of crufty code. What me and Peter (and Jano, I guess, since he posted the series to begin with ;) are arguing is that such a scenario is not very reasonable and we should stop pretending it is, by keeping around support for RHEL 6 but requiring a reasonably modern QEMU. > At least we have some sort of CI environment that tells us when we've > violated some old version or a distro that some developer didn't > consider/use. Of course, by moving the cheese from upstream to the CI > environment - that essentially "moves" the problem of keeping older > version support on the CI environment rather than the upstream > development environment. All the dependency requirements are (at least > to me) mind boggling to try to keep track of. Not sure we document them > anywhere either. What you're looking for is https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=tree;f=guests/vars where we keep track, for each of the projects built on the CentOS CI, of the build dependencies and, for each of the OS we build on, what package needs to be installed in order to satisfy said build dependencies. And yes, it was a *lot* of work to put it together. Keeping it up to date is not that bad, though :) > While perhaps not thought of completely in that manner, perhaps the > *-maint branches should become "the" mechanism for support of older or > more stable supported code. Probably means we need to do a better job at > making sure *-maint branches always get created and of course document > perhaps what "version adjustments" or "dependency changes" occurred for > any particular *-maint branch. Additionally, as part of the review > process consider whether or not a patch [series] should be back ported > into those type branches. That leaves upstream to be relatively fresh or > at least fresh to some period of time chosen. I don't think we want to use maint branches for that. We should just keep doing regular releases and, once vendors have lost interest in keeping their downstream libvirt builds updated besides critical issues, move on - as they already have. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
