On Mon, Jun 03, 2019 at 08:16:29PM +0200, Cornelia Huck wrote: > On Mon, 3 Jun 2019 14:02:16 -0400 > John Snow <js...@redhat.com> wrote: > > > On 6/3/19 8:26 AM, Markus Armbruster wrote: > > > 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 would rather not support Python2 a day after the clock expires.
Me neither. > > > > > 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. > > I think the idea was that folks might actually develop on a 'stable' > distro (in a previous life, I used to complain quite often that > building QEMU on a stable distro broke... it was one of my main > development machines, but not controlled by me). Good point. > > > > > 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. > > It depends on how old the distro is and what update policy it > uses... if parts of it are regularly updated, it might actually be > usable. In this case, I think we really need to interpret our policy > to include EPEL, or it is completely nuts. Let's do that, please. If we simply include EPEL in our policy we don't need to treat Python as special. -- Eduardo
