On Thu, Jul 16, 2015 at 11:11:01AM +0200, Christophe Fergeau wrote: > On Mon, Jul 13, 2015 at 02:45:21PM +0100, Zeeshan Ali (Khattak) wrote: > > On Fri, Jul 10, 2015 at 5:04 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > > > Patches of yours broke the build, you have a strong opinion on the right way > > > to fix it, in such situations I usually go the extra mile to > > > convince others that it's the best way :) That's why I'm a bit surprised > > > this drags for so long with no real attempt at finding some common > > > ground. > > > > I gave you an easy way out of this dragging discussion and even > > promised to implement either of the solutions you want me to. You're > > still not happy so I'll just bump the dependencies now. Feel free to > > implement ugly hack solution. I'm out here.. > > Thanks a lot for pushing an unreviewed patch after not wanting to go > through proper patch discussion (ie do a bit of research in order to > address the concerns which were raised rather than making up excuses for > not doing it), that's appreciated! > > After 10 minutes looking around, Ubuntu 14.04 LTS has libvirt 1.2.2 and > SLES 12 has 1.2.5, both have long support cycles and a too old libvirt. > Apart from these, supported Fedoras, latest Debian stable, opensuse 13.2 > and EL7.1 all have new enough libvirt. > With this data in mind, and unless people from the impacted distros > speak up, raising the requirement is probably reasonable enough. So for the record, my viewpoint is the time since the feature was released is pretty irrelevant. The important thing is what distros have the neccessary versions, as that directly impacts how easy it is for app developers to consume new libvirt-glib releases. If there is a tradeoff between ugly #ifdefs and app developers not being able to use libvirt-glib, then my preference is towards #ifdefs as that only inconveniences a handful of people (ie us) in a pretty limited manner, as opposed to inconveniencing potentially 100's or 1000's of potential developers. In the core libvirt we take this to the extreme and currently aim to build on *every* Linux distro since RHEL-5 vintage. In the libvirt-glib I think we have more flexibility, mostly because you really want to have gobject introspection, so that immediately rules out anything older than RHEL-7 vintage as an interesting distro target. In general though I'd still be against increasing the min required libvirt beyond the version in RHEL-7.0 and other comparable age distros. Since we've already increased the dep in this case though, I won't object / ask for revert. In future though, we should avoid increasing the min required dep on libvirt or glib beyond what's available in the distros mentioned above, because as I mention above it removes a small burden from us maintainers in favour of a large burden on downstream users/developers which is not a net benefit IMHO. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list