Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

Hi, name change might be considered, but I do not think it will make a big difference. People do not see vdsm too often (installed by host deploy, managed by engine..). But trying to make sure that (all?) component versions in a project are the same is not a good idea if you ask me. You are not going to rebuild everything when a hot fix is needed, but granted, you might use minor numbers so the versions will at least start with the same numbers. Or will we force a version bump and rebuild to unchanged component, when others were updated for a given release? (we have components like that - ovirt-scheduler-proxy for example) Engine does not depend on an exact vdsm version, we have gradual feature degradation built in in form of capabilities, machine type and cluster levels so it should be totally up to the user what version of vdsm is used. The same we do not control libvirt or kernel. Some of the components (at least on my side) are completely usable without oVirt and when oVirt is released it just gets the latest stable bits available. Why don't we treat oVirt as a package distribution it is? The long term plan still is to break the monoliths (like vdsm or engine) and the possibly new teams (or community) might have different needs.. we might even want to promote reuse of some of the components (like [2]) in oVirt unrelated way and I would really love to see that kind of adoption. We are trying to keep so much control that we are an open project, but not a community one (where the community can influence future plans, release schedules, workflows or processes). Neither Fedora, nor RHEL (Debian, ..) try to control the version of components. They depend purely on package dependencies and separate component development from distribution compose processes (something we lack..). Even OpenStack abandoned the unified versioning last year (at least partially) [1]. We decided to use similar age based versioning like described in [1] when I was still part of the Anaconda team and it worked perfectly fine. I really wish we would loosen the project coupling (and processes) instead of tightening it. Sadly everything we have done lately is going in the tightening direction... TL;DR: Please let us use whatever versions of packages we want, release as often as we want and just take the latest bits to compose the oVirt distribution. Most of the components we have handle that just fine. [1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and please pay particular attention to the last section and especially the last two paragraphs in it) [2] There was a thread about vdsm RPMs being too granular: http://lists.ovirt.org/pipermail/devel/2016-January/012185.html -- Martin Sivak oVirt / SLA _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel