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.