John Snow <js...@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 didn't bother checking Debian, Ubuntu LTS and SLES.
For hosts other than Linux, we're less ambitious.
