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

From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [Qemu-devel] Deprecation policy and build dependencies
Date: Mon, 3 Jun 2019 14:02:16 -0400	[thread overview]
Message-ID: <236db86d-52df-5537-4f33-f3c09bbb6289@redhat.com> (raw)
In-Reply-To: <871s0asvli.fsf@dusky.pond.sub.org>

On 6/3/19 8:26 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
> 
>> On 5/31/19 3:24 PM, Eduardo Habkost wrote:
>>> Long story short: I would really like to drop support for Python
>>> 2 in QEMU 4.1.
> 
> The sooner, the better, as far as I'm concerned.
> 
>>> What exactly prevents us from doing this?  Does our deprecation
>>> policy really apply to build dependencies?
>>>
>>
>> Normally I'd say it's only nice to also follow the depreciation policy
>> for tooling as well to give people a chance to switch away, but with
>> regards to Python2, I feel like we're in the clear to drop it for the
>> first release that will happen after the Python2 doomsday clock.
>>
>> (So, probably 4.2.)
> 
> In addition to our feature deprecation policity, we have a "Supported
> build platforms" policy (commit 45b47130f4b).  The most common holdback
> is this one:
> 
>     For distributions with long-lifetime releases, the project will aim
>     to support the most recent major version at all times. Support for
>     the previous major version will be dropped 2 years after the new
>     major version is released. For the purposes of identifying supported
>     software versions, the project will look at RHEL, Debian, Ubuntu
>     LTS, and SLES distros. Other long-lifetime distros will be assumed
>     to ship similar software versions.
> 
> RHEL-7 has Python 3 only in EPEL.  RHEL-8 came out last month.  Unless
> we interpret our policy to include EPEL, this means supporting Python 2
> for some 16 months after upstream Python retires it.  My personal
> opinion: nuts.
> 

I would rather not support Python2 a day after the clock expires.

> I didn't bother checking Debian, Ubuntu LTS and SLES.
> 
> For hosts other than Linux, we're less ambitious.
> 

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?

RHEL7 uses a 1.5.3 based version. I don't think it matters if we update
4.2 to be Python3 only, really.