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

[John Snow <jsnow@redhat.com>]

On 6/3/19 2:17 PM, Peter Maydell wrote:
> On Mon, 3 Jun 2019 at 19:02, John Snow <jsnow@redhat.com> wrote:
>> That policy strikes me as weird, because RHEL7 is not going to be, in
>> general, using the latest and greatest QEMU. Usually stable versions of
>> distros stick with the versions of the programs that came out at the time.
>>
>> What's the benefit of making sure that stable platforms can continue to
>> run the *newest* QEMU? Is this even a reasonable restriction? If you are
>> running RHEL7, how many projects do you expect to be able to git clone
>> and build and have that work with the rest of your legacy/stable
>> dependencies?
> 
> The benefit is that in general people who want to build QEMU
> from source can do so. I don't want us to be the kind of
> project that needs latest-and-greatest-foo for everything
> to build, because that sort of project is pretty infuriating
> to try to work with if you're an occasional contributor.
> "Builds on LTS distros" is an easy-to-express way to keep
> things from getting out of hand.
> 
> Plus a bunch of the build machines we do testing on are
> not running bleeding edge distros, and as Connie says plenty
> of developers do QEMU development on non-bleeding-edge versions
> (my primary dev box run an LTS Ubuntu).
> 

I get it, we don't want to require Python 3.8 because some dev wanted
assignment conditionals -- but we're talking about Python 2 here, which
suffers its EOL by the end of this calendar year.

So do we think it's reasonable to drop support for Python2 for the
release that comes out after Python2's EOL, or do we insist on 2x3
simultaneous support for years more?

--js