[libvirt] [libvirt-glib PATCHv5 7/7] gobject: Add wrapper for virNetworkGetDHCPLeases

[Daniel P. Berrange]

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 at redhat.com> 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 :|