[libvirt] [PATCH glib] README: formally document intended platform support targets

Daniel P. Berrange berrange at redhat.com
Wed Jul 22 14:04:25 UTC 2015

On Wed, Jul 22, 2015 at 02:54:17PM +0100, Zeeshan Ali (Khattak) wrote:
> On Wed, Jul 22, 2015 at 2:02 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > Give users an indication of what distro platforms the project
> > intends to be buildable on. This policy will be used to decide
> > when it is appropriate to increase the minimum required versions
> > of external dependancies.
> While this sounds like a good idea at first, being so specific about
> versions makes it a very bad one IMO. i-e this list will get outdated
> all the time and none of us will remember to update it often enough
> for it to be useful.

The intention isn't actually to updated the README with new releases,
rather just give this as an illustrative example, to explain how the
policy works. ie accepts RHEL-7, but discounts RHEL-6.

> Also IMO selecting a few downstreams isn't a good idea in upstream
> project. We really should be distro-agnostic and libosinfo should be
> buildable on any GNU/Linux distro. The idea here is to convey the
> message "We do care a lot about individual distros" but unless this
> list is a long one, we are actually saying "We only care of these
> distros".

It isn't about favouring specific distros, it is about selecting
a handful of distros to use as representative samples. Distros
released at a similar time tend to have similar package versions,
so we're using this set of distros as a way to guage the typically
available set of min versions across the bigger pool.

> As I said before, I think we only need to define a time frame in
> upstream (i-e we guarantee we won't bump any dep to anything newer
> than X amount of time) and be done with it. No need to focus on any
> particular distros, just provide enough time for distros. In worse
> case, they'd have to cherry-pick fixes from newer version of software,
> which is what long-term support downstream typically imply anyway.

Giving time based rules really doesn't work with enterprise distros
as they (quite reasonably) stick with older versions and shouldn't be
expected to rebase, and I want developers working on such distros to
be able to consume newer libvirt-glib if they desire, and likewise I
want such users to be able to contribute to the development of the
library. Many corporate developers don't have the luxury of using
distros like Fedora as their dev platform, so if we don't ensure we
remain easily buildable on reasonably current enterprise platforms,
we are making life hard for those developers to contribute to the
project. This isn't a theoretical problem - it has come up time &
again with libvirt that users can only use RHEL as their build
platform and not Fefora.

|: 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 :|

More information about the libvir-list mailing list