* [Qemu-devel] Deprecation policy and build dependencies @ 2019-05-31 19:24 Eduardo Habkost 2019-05-31 22:06 ` John Snow 2019-06-05 15:44 ` Daniel P. Berrangé 0 siblings, 2 replies; 24+ messages in thread From: Eduardo Habkost @ 2019-05-31 19:24 UTC (permalink / raw) To: qemu-devel Cc: Peter Maydell, Daniel P. Berrange, Philippe Mathieu-Daudé, Markus Armbruster, Cleber Rosa, John Snow Long story short: I would really like to drop support for Python 2 in QEMU 4.1. What exactly prevents us from doing this? Does our deprecation policy really apply to build dependencies? -- Eduardo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-05-31 19:24 [Qemu-devel] Deprecation policy and build dependencies Eduardo Habkost @ 2019-05-31 22:06 ` John Snow 2019-06-03 12:26 ` Markus Armbruster 2019-06-05 15:44 ` Daniel P. Berrangé 1 sibling, 1 reply; 24+ messages in thread From: John Snow @ 2019-05-31 22:06 UTC (permalink / raw) To: Eduardo Habkost, qemu-devel Cc: Peter Maydell, Cleber Rosa, Daniel P. Berrange, Markus Armbruster, Philippe Mathieu-Daudé 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. > > 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.) --js ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-05-31 22:06 ` John Snow @ 2019-06-03 12:26 ` Markus Armbruster 2019-06-03 18:02 ` John Snow 2019-06-05 15:50 ` Daniel P. Berrangé 0 siblings, 2 replies; 24+ messages in thread From: Markus Armbruster @ 2019-06-03 12:26 UTC (permalink / raw) To: John Snow Cc: Peter Maydell, Daniel P. Berrange, Eduardo Habkost, qemu-devel, Cleber Rosa, Philippe Mathieu-Daudé 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 didn't bother checking Debian, Ubuntu LTS and SLES. For hosts other than Linux, we're less ambitious. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 12:26 ` Markus Armbruster @ 2019-06-03 18:02 ` John Snow 2019-06-03 18:16 ` Cornelia Huck ` (2 more replies) 2019-06-05 15:50 ` Daniel P. Berrangé 1 sibling, 3 replies; 24+ messages in thread From: John Snow @ 2019-06-03 18:02 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Daniel P. Berrange, Eduardo Habkost, qemu-devel, Cleber Rosa, Philippe Mathieu-Daudé 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:02 ` John Snow @ 2019-06-03 18:16 ` Cornelia Huck 2019-06-03 19:44 ` Eduardo Habkost 2019-06-04 7:14 ` Philippe Mathieu-Daudé 2019-06-03 18:17 ` Peter Maydell 2019-06-04 5:26 ` Gerd Hoffmann 2 siblings, 2 replies; 24+ messages in thread From: Cornelia Huck @ 2019-06-03 18:16 UTC (permalink / raw) To: John Snow Cc: Peter Maydell, Daniel P. Berrange, Eduardo Habkost, qemu-devel, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé On Mon, 3 Jun 2019 14:02:16 -0400 John Snow <jsnow@redhat.com> wrote: > 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. 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). > > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:16 ` Cornelia Huck @ 2019-06-03 19:44 ` Eduardo Habkost 2019-06-04 7:14 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 24+ messages in thread From: Eduardo Habkost @ 2019-06-03 19:44 UTC (permalink / raw) To: Cornelia Huck Cc: Peter Maydell, Daniel P. Berrange, Philippe Mathieu-Daudé, Markus Armbruster, qemu-devel, Cleber Rosa, John Snow On Mon, Jun 03, 2019 at 08:16:29PM +0200, Cornelia Huck wrote: > On Mon, 3 Jun 2019 14:02:16 -0400 > John Snow <jsnow@redhat.com> wrote: > > > 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. 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:16 ` Cornelia Huck 2019-06-03 19:44 ` Eduardo Habkost @ 2019-06-04 7:14 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 24+ messages in thread From: Philippe Mathieu-Daudé @ 2019-06-04 7:14 UTC (permalink / raw) To: Cornelia Huck, John Snow Cc: Peter Maydell, Daniel P. Berrange, Eduardo Habkost, qemu-devel, Markus Armbruster, Cleber Rosa On 6/3/19 8:16 PM, Cornelia Huck wrote: > On Mon, 3 Jun 2019 14:02:16 -0400 > John Snow <jsnow@redhat.com> wrote: [...] >> 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. > > 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). > >> >> 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. Red Hat supports Docker on RHEL 7 and above. Docker solved all my problems, as long as a host can install Docker, I can build on old or edge images. I don't install plenty of dependencies on my testing hosts, but in trashable docker images. For regular testing I use image snapshots. You need a sysadmin (or root access) to install the docker daemon however. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:02 ` John Snow 2019-06-03 18:16 ` Cornelia Huck @ 2019-06-03 18:17 ` Peter Maydell 2019-06-03 18:21 ` John Snow 2019-06-04 5:26 ` Gerd Hoffmann 2 siblings, 1 reply; 24+ messages in thread From: Peter Maydell @ 2019-06-03 18:17 UTC (permalink / raw) To: John Snow Cc: Daniel P. Berrange, Eduardo Habkost, QEMU Developers, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé 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). thanks -- PMM ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:17 ` Peter Maydell @ 2019-06-03 18:21 ` John Snow 2019-06-03 18:27 ` Peter Maydell 0 siblings, 1 reply; 24+ messages in thread From: John Snow @ 2019-06-03 18:21 UTC (permalink / raw) To: Peter Maydell Cc: Daniel P. Berrange, Eduardo Habkost, QEMU Developers, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:21 ` John Snow @ 2019-06-03 18:27 ` Peter Maydell 2019-06-03 18:38 ` John Snow 2019-06-04 5:31 ` Markus Armbruster 0 siblings, 2 replies; 24+ messages in thread From: Peter Maydell @ 2019-06-03 18:27 UTC (permalink / raw) To: John Snow Cc: Daniel P. Berrange, Eduardo Habkost, QEMU Developers, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé On Mon, 3 Jun 2019 at 19:21, John Snow <jsnow@redhat.com> wrote: > 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? I don't have a strong opinion on Python in particular, but I think it would be nicer to avoid the "python is a special snowflake" effect. Would it really be so bad for it to just be "drop it when it falls off the last LTS distro" like the rest of our dependencies ? thanks -- PMM ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:27 ` Peter Maydell @ 2019-06-03 18:38 ` John Snow 2019-06-04 5:31 ` Markus Armbruster 1 sibling, 0 replies; 24+ messages in thread From: John Snow @ 2019-06-03 18:38 UTC (permalink / raw) To: Peter Maydell Cc: Daniel P. Berrange, Eduardo Habkost, QEMU Developers, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé On 6/3/19 2:27 PM, Peter Maydell wrote: > On Mon, 3 Jun 2019 at 19:21, John Snow <jsnow@redhat.com> wrote: >> 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? > > I don't have a strong opinion on Python in particular, but > I think it would be nicer to avoid the "python is a special > snowflake" effect. Would it really be so bad for it to just > be "drop it when it falls off the last LTS distro" like the > rest of our dependencies ? > > thanks > -- PMM > When it comes to supporting both 2 and 3 simultaneously yes; it's in my opinion not trivial to maintain a growing testing and utility infrastructure that works in versions as disparate as 2.7 and 3.7 from RHEL7 all the way to Fedora 30. It's not going to get easier, either. (Especially not after EOL.) For comparison, at least when we target different versions of compilers, we are at least targeting the same version of the language... If you are running a stable or outdated distro and you want to build bleeding edge QEMU and you cannot somehow find out how to get Python3 on your machine after the official EOL of python2, I am not sure that should become the developer's burden. I don't think we are being too unreasonably avant-garde about adopting technologies that are too new. --js ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:27 ` Peter Maydell 2019-06-03 18:38 ` John Snow @ 2019-06-04 5:31 ` Markus Armbruster 2019-06-04 15:51 ` John Snow 1 sibling, 1 reply; 24+ messages in thread From: Markus Armbruster @ 2019-06-04 5:31 UTC (permalink / raw) To: Peter Maydell Cc: Daniel P. Berrange, Eduardo Habkost, John Snow, QEMU Developers, Cleber Rosa, Philippe Mathieu-Daudé Peter Maydell <peter.maydell@linaro.org> writes: > On Mon, 3 Jun 2019 at 19:21, John Snow <jsnow@redhat.com> wrote: >> 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. "Not because some dev wanted assignment conditionals" is the non-reason. Let me spell out the reason: supporting Python 2 is expensive for us. As the amount of Python code grows, it gets more and more expensive. Is this really time and effort well spent? >> 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? > > I don't have a strong opinion on Python in particular, but > I think it would be nicer to avoid the "python is a special > snowflake" effect. Lots of things are nice. Limited resources dictate we can only get some of them. > Would it really be so bad for it to just > be "drop it when it falls off the last LTS distro" like the > rest of our dependencies ? In my experience maintaining and evolving the QAPI generators, supporting both Python 2 and 3 is a constant distraction that adds up over time. It's all manual; we decided against adopting one of tool chains made for dealing with this mess. I'd rather think about how to solve real user problems like deprecation information or command line introspection than deal with Python 2 vs. 3 arcana. Just the other day, I flagged an innocent-looking simplification of some non-QAPI Python code that changed semantics subtly on Python 2, impact unknown. The developer did not know. The fact that I waste precious brain capacity on knowing this shit (pardon my French) is a bloody shame. Well, some of this shit, because I've screwed it up myself, too. The sooner we stop the bleeding, the better. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-04 5:31 ` Markus Armbruster @ 2019-06-04 15:51 ` John Snow 0 siblings, 0 replies; 24+ messages in thread From: John Snow @ 2019-06-04 15:51 UTC (permalink / raw) To: Markus Armbruster, Peter Maydell Cc: Philippe Mathieu-Daudé, Cleber Rosa, Daniel P. Berrange, Eduardo Habkost, QEMU Developers On 6/4/19 1:31 AM, Markus Armbruster wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On Mon, 3 Jun 2019 at 19:21, John Snow <jsnow@redhat.com> wrote: >>> 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. > > "Not because some dev wanted assignment conditionals" is the non-reason. > Let me spell out the reason: supporting Python 2 is expensive for us. > As the amount of Python code grows, it gets more and more expensive. > > Is this really time and effort well spent? > I'd just like to clarify that you and I are arguing the same point. I used that non-reason intentionally, arguing that we don't want a trivial feature, we're talking about the major deprecation of an entire version of a language. I picked a far-fetched, very bleeding edge version (and a feature in it that matched, sorry, been doing a lot of Python lately) to counter Peter's point that we didn't want to support bleeding-edge stuff "just because." Sorry if I didn't articulate this point well. >>> 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? >> >> I don't have a strong opinion on Python in particular, but >> I think it would be nicer to avoid the "python is a special >> snowflake" effect. > > Lots of things are nice. Limited resources dictate we can only get some > of them. > >> Would it really be so bad for it to just >> be "drop it when it falls off the last LTS distro" like the >> rest of our dependencies ? > > In my experience maintaining and evolving the QAPI generators, > supporting both Python 2 and 3 is a constant distraction that adds up > over time. It's all manual; we decided against adopting one of tool > chains made for dealing with this mess. I'd rather think about how to > solve real user problems like deprecation information or command line > introspection than deal with Python 2 vs. 3 arcana. > > Just the other day, I flagged an innocent-looking simplification of some > non-QAPI Python code that changed semantics subtly on Python 2, impact > unknown. The developer did not know. The fact that I waste precious > brain capacity on knowing this shit (pardon my French) is a bloody > shame. Well, some of this shit, because I've screwed it up myself, too. > > The sooner we stop the bleeding, the better. > I agree, and it looks like we have consensus that because RHEL7 has EPEL, we can drop Python 2 support. I think. What wasn't made clear to me yet is in which version we may do so. I think I suggested 4.2, and nobody agreed or disagreed with that point. --js ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 18:02 ` John Snow 2019-06-03 18:16 ` Cornelia Huck 2019-06-03 18:17 ` Peter Maydell @ 2019-06-04 5:26 ` Gerd Hoffmann 2 siblings, 0 replies; 24+ messages in thread From: Gerd Hoffmann @ 2019-06-04 5:26 UTC (permalink / raw) To: John Snow Cc: Peter Maydell, Daniel P. Berrange, Eduardo Habkost, qemu-devel, Markus Armbruster, Cleber Rosa, Philippe Mathieu-Daudé Hi, > >> 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.) Makes sense to me. > > RHEL-7 has Python 3 only in EPEL. That'll change with 7.7 btw. Beside that I'd say EPEL is good enough. > What's the benefit of making sure that stable platforms can continue to > run the *newest* QEMU? Well, my development workstation runs RHEL-7 ... cheers, Gerd ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-03 12:26 ` Markus Armbruster 2019-06-03 18:02 ` John Snow @ 2019-06-05 15:50 ` Daniel P. Berrangé 2019-06-05 20:13 ` Eduardo Habkost 1 sibling, 1 reply; 24+ messages in thread From: Daniel P. Berrangé @ 2019-06-05 15:50 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Eduardo Habkost, John Snow, qemu-devel, Cleber Rosa, Philippe Mathieu-Daudé On Mon, Jun 03, 2019 at 02:26:49PM +0200, 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. We've not said whether this refers to only base repos, or whether addon repos are accepted. IMHO, we are reasonably justified in saying RHEL-7 as a build platform covers any repo provided by Red Hat, which would give us Python3 via software collections. I think it would be reasonable to also state it covers EPEL, since EPEL is such a commonly used repo with RHEL. IOW, I don't think RHEL-7 support as a build platform blocks us from dropping py2. We merely need to tweak our build platforms doc to clarify our intent wrt add-on yum repos. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 15:50 ` Daniel P. Berrangé @ 2019-06-05 20:13 ` Eduardo Habkost 2019-06-05 20:42 ` Eric Blake 0 siblings, 1 reply; 24+ messages in thread From: Eduardo Habkost @ 2019-06-05 20:13 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Peter Maydell, John Snow, Markus Armbruster, qemu-devel, Cleber Rosa, Philippe Mathieu-Daudé On Wed, Jun 05, 2019 at 04:50:06PM +0100, Daniel P. Berrangé wrote: > On Mon, Jun 03, 2019 at 02:26:49PM +0200, 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. > > We've not said whether this refers to only base repos, or whether addon > repos are accepted. IMHO, we are reasonably justified in saying RHEL-7 > as a build platform covers any repo provided by Red Hat, which would > give us Python3 via software collections. I think it would be reasonable > to also state it covers EPEL, since EPEL is such a commonly used repo > with RHEL. > > IOW, I don't think RHEL-7 support as a build platform blocks us from > dropping py2. We merely need to tweak our build platforms doc to clarify > our intent wrt add-on yum repos. If we clarify the docs in QEMU 4.1, is there anything that prevents us from removing Python 2 support in QEMU 4.1 too? -- Eduardo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 20:13 ` Eduardo Habkost @ 2019-06-05 20:42 ` Eric Blake 2019-06-05 20:49 ` Eduardo Habkost ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Eric Blake @ 2019-06-05 20:42 UTC (permalink / raw) To: Eduardo Habkost, Daniel P. Berrangé Cc: Peter Maydell, John Snow, Markus Armbruster, qemu-devel, Cleber Rosa, Philippe Mathieu-Daudé [-- Attachment #1: Type: text/plain, Size: 945 bytes --] On 6/5/19 3:13 PM, Eduardo Habkost wrote: >> IOW, I don't think RHEL-7 support as a build platform blocks us from >> dropping py2. We merely need to tweak our build platforms doc to clarify >> our intent wrt add-on yum repos. > > If we clarify the docs in QEMU 4.1, is there anything that > prevents us from removing Python 2 support in QEMU 4.1 too? My take (but not definitive): if we have any CI setups that are testing RHEL 7 without software collections and/or EPEL, then save Python 2 removal for 4.2 to give us time to update CI setups. But if all of our CI setups are already fine, and we clarify the docs, then I'm all for getting rid of Python 2 support in 4.1. Similarly, if we are going to outlaw in-tree builds, let's get that done in 4.1 instead of waiting yet another release. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 20:42 ` Eric Blake @ 2019-06-05 20:49 ` Eduardo Habkost 2019-06-05 22:02 ` Eric Blake 2019-06-06 5:22 ` Markus Armbruster 2019-06-06 9:19 ` Daniel P. Berrangé 2 siblings, 1 reply; 24+ messages in thread From: Eduardo Habkost @ 2019-06-05 20:49 UTC (permalink / raw) To: Eric Blake Cc: Peter Maydell, Daniel P. Berrangé, Philippe Mathieu-Daudé, Markus Armbruster, qemu-devel, Cleber Rosa, John Snow On Wed, Jun 05, 2019 at 03:42:39PM -0500, Eric Blake wrote: > On 6/5/19 3:13 PM, Eduardo Habkost wrote: > > >> IOW, I don't think RHEL-7 support as a build platform blocks us from > >> dropping py2. We merely need to tweak our build platforms doc to clarify > >> our intent wrt add-on yum repos. > > > > If we clarify the docs in QEMU 4.1, is there anything that > > prevents us from removing Python 2 support in QEMU 4.1 too? > > My take (but not definitive): if we have any CI setups that are testing > RHEL 7 without software collections and/or EPEL, then save Python 2 > removal for 4.2 to give us time to update CI setups. But if all of our > CI setups are already fine, and we clarify the docs, then I'm all for > getting rid of Python 2 support in 4.1. If we do this soon, CI system owners will have at least 9 weeks to fix them before 4.1.0 is released. > > Similarly, if we are going to outlaw in-tree builds, let's get that done > in 4.1 instead of waiting yet another release. I'm missing the context on this. Is this from a separate discussion? -- Eduardo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 20:49 ` Eduardo Habkost @ 2019-06-05 22:02 ` Eric Blake 0 siblings, 0 replies; 24+ messages in thread From: Eric Blake @ 2019-06-05 22:02 UTC (permalink / raw) To: Eduardo Habkost Cc: Peter Maydell, Daniel P. Berrangé, Philippe Mathieu-Daudé, Markus Armbruster, qemu-devel, Cleber Rosa, John Snow [-- Attachment #1: Type: text/plain, Size: 1623 bytes --] On 6/5/19 3:49 PM, Eduardo Habkost wrote: > On Wed, Jun 05, 2019 at 03:42:39PM -0500, Eric Blake wrote: >> On 6/5/19 3:13 PM, Eduardo Habkost wrote: >> >>>> IOW, I don't think RHEL-7 support as a build platform blocks us from >>>> dropping py2. We merely need to tweak our build platforms doc to clarify >>>> our intent wrt add-on yum repos. >>> >>> If we clarify the docs in QEMU 4.1, is there anything that >>> prevents us from removing Python 2 support in QEMU 4.1 too? >> >> My take (but not definitive): if we have any CI setups that are testing >> RHEL 7 without software collections and/or EPEL, then save Python 2 >> removal for 4.2 to give us time to update CI setups. But if all of our >> CI setups are already fine, and we clarify the docs, then I'm all for >> getting rid of Python 2 support in 4.1. > > If we do this soon, CI system owners will have at least 9 weeks > to fix them before 4.1.0 is released. > >> >> Similarly, if we are going to outlaw in-tree builds, let's get that done >> in 4.1 instead of waiting yet another release. > > I'm missing the context on this. Is this from a separate discussion? Yes, separate threads (for example, this one: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02553.html), but related in that it is a build change that would affect existing development and CI. If we're going to make life harder by pulling the plug on old ways, we might as well pull the plug on multiple things at once. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 20:42 ` Eric Blake 2019-06-05 20:49 ` Eduardo Habkost @ 2019-06-06 5:22 ` Markus Armbruster 2019-06-06 9:19 ` Daniel P. Berrangé 2 siblings, 0 replies; 24+ messages in thread From: Markus Armbruster @ 2019-06-06 5:22 UTC (permalink / raw) To: Eric Blake Cc: Peter Maydell, Daniel P. Berrangé, Eduardo Habkost, Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster, Cleber Rosa, John Snow Eric Blake <eblake@redhat.com> writes: > On 6/5/19 3:13 PM, Eduardo Habkost wrote: > >>> IOW, I don't think RHEL-7 support as a build platform blocks us from >>> dropping py2. We merely need to tweak our build platforms doc to clarify >>> our intent wrt add-on yum repos. >> >> If we clarify the docs in QEMU 4.1, is there anything that >> prevents us from removing Python 2 support in QEMU 4.1 too? > > My take (but not definitive): if we have any CI setups that are testing > RHEL 7 without software collections and/or EPEL, then save Python 2 > removal for 4.2 to give us time to update CI setups. But if all of our > CI setups are already fine, and we clarify the docs, then I'm all for > getting rid of Python 2 support in 4.1. There's still time to update CI setups without undue haste. But I agree we don't want to lose CI even temporarily just to expedite getting rid of Python 2. > Similarly, if we are going to outlaw in-tree builds, let's get that done > in 4.1 instead of waiting yet another release. For that we need patches. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 20:42 ` Eric Blake 2019-06-05 20:49 ` Eduardo Habkost 2019-06-06 5:22 ` Markus Armbruster @ 2019-06-06 9:19 ` Daniel P. Berrangé 2 siblings, 0 replies; 24+ messages in thread From: Daniel P. Berrangé @ 2019-06-06 9:19 UTC (permalink / raw) To: Eric Blake Cc: Peter Maydell, Eduardo Habkost, Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster, Cleber Rosa, John Snow On Wed, Jun 05, 2019 at 03:42:39PM -0500, Eric Blake wrote: > On 6/5/19 3:13 PM, Eduardo Habkost wrote: > > >> IOW, I don't think RHEL-7 support as a build platform blocks us from > >> dropping py2. We merely need to tweak our build platforms doc to clarify > >> our intent wrt add-on yum repos. > > > > If we clarify the docs in QEMU 4.1, is there anything that > > prevents us from removing Python 2 support in QEMU 4.1 too? > > My take (but not definitive): if we have any CI setups that are testing > RHEL 7 without software collections and/or EPEL, then save Python 2 > removal for 4.2 to give us time to update CI setups. But if all of our > CI setups are already fine, and we clarify the docs, then I'm all for > getting rid of Python 2 support in 4.1. The centos7 dockerfile will need to add the extra repo to pull this in. I don't see any issue with that getting fixed in this cycle. As for any CI maintained by third parties outside QEMU tree, they'll just have to adapt themselves. It is not difficult to add repos, so again I don't see a big reason to delay. If we delay chances are they won't bother to update their CI at all until we make the py3 change in 4.2 anyway. > Similarly, if we are going to outlaw in-tree builds, let's get that done > in 4.1 instead of waiting yet another release. I don't think there was any hard objection, someone just needs to write the patch... Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-05-31 19:24 [Qemu-devel] Deprecation policy and build dependencies Eduardo Habkost 2019-05-31 22:06 ` John Snow @ 2019-06-05 15:44 ` Daniel P. Berrangé 2019-06-05 18:13 ` Eduardo Habkost 1 sibling, 1 reply; 24+ messages in thread From: Daniel P. Berrangé @ 2019-06-05 15:44 UTC (permalink / raw) To: Eduardo Habkost Cc: Peter Maydell, Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster, Cleber Rosa, John Snow On Fri, May 31, 2019 at 04:24:29PM -0300, Eduardo Habkost wrote: > Long story short: I would really like to drop support for Python > 2 in QEMU 4.1. > > What exactly prevents us from doing this? Does our deprecation > policy really apply to build dependencies? In general I do *not* consider our deprecation policy to apply to *mandatory* build dependancies. Instead our platform support policy applies. The rationale is that mandatory build dependancies are not something that can be considered on a case by case basis. To build QEMU on any given platform, *all* the mandatory build deps must be satisfied by that platform. Increasing min version of any single mandatory, build dep will effectively exclude a host build target. IOW, when we drop a build target we can consider updating min version of *all* mandatory build deps at the same time. Where the deprecation policy could come into play is if we want to drop an *optional* build dependancy for certain platforms. eg librbd is an optional build dep and we might have some reason we want to increase the min version despite it not being present in all our supported platforms. This could be a case to mark the "rbd" feature as deprecated on certain build platforms. Thus to answer your python 2 question, we should ask which of our build targets cannot support python 3 ? Obviously we know the answer to that is RHEL-7. Except there is some fuzziness in there because it depends on what you define "RHEL-7" to be. There are several possible answers a. RHEL-7 covers only the stuff in the basic yum repos b. RHEL-7 covers packages in any yum repos shipped by Red Hat c. RHEL-7 covers packages in any yum repos shipped by Red Hat or EPEL d. RHEL-7 covers packages in any yum repo available for use with RHEL-7, provided by any vendor The platform support policy has not documented which of these possiblities we're targetting. If we consider it to mean (a), then there's no way to use py3 with RHEL-7. With (b), (c), or (d) it is possible to get py3 available on RHEL-7 by enabling suitable repos. Personally I think it would be fine for use to consider (b) or (c) to be our intended interpretation for platform support policy. In this interpretation it is possible for developers to get Python 3 on RHEL-7 by enabling the Red Hat Software collection repos: https://developers.redhat.com/products/softwarecollections/hello-world/#fndtn-windows This implies we *can* drop python2 from QEMU *and* keep RHEL-7 as a supported target. Also note that the platform support policy didn't say anything about RHEL minor updates. ie it does not distinguish RHEL-7.0 from RHEL-7.6, despite fact that some packages get major version rebases. I think we should clarify that we mean "latest available updates" for our supported platforms. ie 7.6 is supported, 7.0 is *not* supported. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 15:44 ` Daniel P. Berrangé @ 2019-06-05 18:13 ` Eduardo Habkost 2019-06-06 9:23 ` Daniel P. Berrangé 0 siblings, 1 reply; 24+ messages in thread From: Eduardo Habkost @ 2019-06-05 18:13 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Peter Maydell, Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster, Cleber Rosa, John Snow On Wed, Jun 05, 2019 at 04:44:03PM +0100, Daniel P. Berrangé wrote: [...] > Thus to answer your python 2 question, we should ask which of our build > targets cannot support python 3 ? > > Obviously we know the answer to that is RHEL-7. Except there is some > fuzziness in there because it depends on what you define "RHEL-7" to > be. There are several possible answers > > a. RHEL-7 covers only the stuff in the basic yum repos > b. RHEL-7 covers packages in any yum repos shipped by Red Hat > c. RHEL-7 covers packages in any yum repos shipped by Red Hat or EPEL > d. RHEL-7 covers packages in any yum repo available for use > with RHEL-7, provided by any vendor > > The platform support policy has not documented which of these possiblities > we're targetting. > > If we consider it to mean (a), then there's no way to use py3 with RHEL-7. > > With (b), (c), or (d) it is possible to get py3 available on RHEL-7 by > enabling suitable repos. > > Personally I think it would be fine for use to consider (b) or (c) to be > our intended interpretation for platform support policy. (c) sounds like the best option, to me. Do we have any reason to prefer (b) instead of (c)? > > In this interpretation it is possible for developers to get Python 3 on > RHEL-7 by enabling the Red Hat Software collection repos: > > https://developers.redhat.com/products/softwarecollections/hello-world/#fndtn-windows > > This implies we *can* drop python2 from QEMU *and* keep RHEL-7 as a > supported target. > > Also note that the platform support policy didn't say anything about > RHEL minor updates. ie it does not distinguish RHEL-7.0 from RHEL-7.6, > despite fact that some packages get major version rebases. I think we > should clarify that we mean "latest available updates" for our supported > platforms. ie 7.6 is supported, 7.0 is *not* supported. Agreed. -- Eduardo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] Deprecation policy and build dependencies 2019-06-05 18:13 ` Eduardo Habkost @ 2019-06-06 9:23 ` Daniel P. Berrangé 0 siblings, 0 replies; 24+ messages in thread From: Daniel P. Berrangé @ 2019-06-06 9:23 UTC (permalink / raw) To: Eduardo Habkost Cc: Peter Maydell, Philippe Mathieu-Daudé, qemu-devel, Markus Armbruster, Cleber Rosa, John Snow On Wed, Jun 05, 2019 at 03:13:08PM -0300, Eduardo Habkost wrote: > On Wed, Jun 05, 2019 at 04:44:03PM +0100, Daniel P. Berrangé wrote: > [...] > > Thus to answer your python 2 question, we should ask which of our build > > targets cannot support python 3 ? > > > > Obviously we know the answer to that is RHEL-7. Except there is some > > fuzziness in there because it depends on what you define "RHEL-7" to > > be. There are several possible answers > > > > a. RHEL-7 covers only the stuff in the basic yum repos > > b. RHEL-7 covers packages in any yum repos shipped by Red Hat > > c. RHEL-7 covers packages in any yum repos shipped by Red Hat or EPEL > > d. RHEL-7 covers packages in any yum repo available for use > > with RHEL-7, provided by any vendor > > > > The platform support policy has not documented which of these possiblities > > we're targetting. > > > > If we consider it to mean (a), then there's no way to use py3 with RHEL-7. > > > > With (b), (c), or (d) it is possible to get py3 available on RHEL-7 by > > enabling suitable repos. > > > > Personally I think it would be fine for use to consider (b) or (c) to be > > our intended interpretation for platform support policy. > > (c) sounds like the best option, to me. Do we have any > reason to prefer (b) instead of (c)? Depends how flexible we want to be. Some enterprise organizations will not allow use of 3rd party repos, even EPEL, only permitting to consume software provided by Red Hat official repos. I'm not too bothered though as I doubt it will be a major problem with likely QEMU contributors. Those restrictive organizations are not likely to allow developers to be involved in upstream communities in the first place, nor consume releases direct from upstream. IOW, I think (c) is fine to allow maximum flexibility for upstream. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-06-06 9:25 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-31 19:24 [Qemu-devel] Deprecation policy and build dependencies Eduardo Habkost 2019-05-31 22:06 ` John Snow 2019-06-03 12:26 ` Markus Armbruster 2019-06-03 18:02 ` John Snow 2019-06-03 18:16 ` Cornelia Huck 2019-06-03 19:44 ` Eduardo Habkost 2019-06-04 7:14 ` Philippe Mathieu-Daudé 2019-06-03 18:17 ` Peter Maydell 2019-06-03 18:21 ` John Snow 2019-06-03 18:27 ` Peter Maydell 2019-06-03 18:38 ` John Snow 2019-06-04 5:31 ` Markus Armbruster 2019-06-04 15:51 ` John Snow 2019-06-04 5:26 ` Gerd Hoffmann 2019-06-05 15:50 ` Daniel P. Berrangé 2019-06-05 20:13 ` Eduardo Habkost 2019-06-05 20:42 ` Eric Blake 2019-06-05 20:49 ` Eduardo Habkost 2019-06-05 22:02 ` Eric Blake 2019-06-06 5:22 ` Markus Armbruster 2019-06-06 9:19 ` Daniel P. Berrangé 2019-06-05 15:44 ` Daniel P. Berrangé 2019-06-05 18:13 ` Eduardo Habkost 2019-06-06 9:23 ` Daniel P. Berrangé
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.