Re: [Qemu-devel] Deprecation policy and build dependencies

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] Deprecation policy and build dependencies
Date: Thu, 6 Jun 2019 10:23:53 +0100	[thread overview]
Message-ID: <20190606092353.GE14300@redhat.com> (raw)
In-Reply-To: <20190605181308.GX22416@habkost.net>

On Wed, Jun 05, 2019 at 03:13:08PM -0300, Eduardo Habkost wrote:
> On Wed, Jun 05, 2019 at 04:44:03PM +0100, Daniel P. Berrangé wrote:
> [...]
> > Thus to answer your python 2 question, we should ask which of our build
> > targets cannot support python 3 ?
> > 
> > Obviously we know the answer to that is RHEL-7. Except there is some
> > fuzziness in there because it depends on what you define "RHEL-7" to
> > be. There are several possible answers
> > 
> >  a. RHEL-7 covers only the stuff in the basic yum repos
> >  b. RHEL-7 covers packages in any yum repos shipped by Red Hat
> >  c. RHEL-7 covers packages in any yum repos shipped by Red Hat or EPEL
> >  d. RHEL-7 covers packages in any yum repo available for use
> >     with RHEL-7,  provided by any vendor
> > 
> > The platform support policy has not documented which of these possiblities
> > we're targetting.
> > 
> > If we consider it to mean (a), then there's no way to use py3 with RHEL-7.
> > 
> > With (b), (c), or (d) it is possible to get py3 available on RHEL-7 by
> > enabling suitable repos.
> > 
> > Personally I think it would be fine for use to consider (b) or (c) to be
> > our intended interpretation for platform support policy.
> 
> (c) sounds like the best option, to me.  Do we have any
> reason to prefer (b) instead of (c)?

Depends how flexible we want to be. Some enterprise organizations will
not allow use of 3rd party repos, even EPEL, only permitting to consume
software provided by Red Hat official repos.  I'm not too bothered though
as I doubt it will be a major problem with likely QEMU contributors. Those
restrictive organizations are not likely to allow developers to be involved
in upstream communities in the first place, nor consume releases direct
from upstream.

IOW, I think (c) is fine to allow maximum flexibility for upstream.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|