All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"John Snow" <jsnow@redhat.com>,
	"Markus Armbruster" <armbru@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: Wed, 5 Jun 2019 17:13:35 -0300	[thread overview]
Message-ID: <20190605201335.GD22416@habkost.net> (raw)
In-Reply-To: <20190605155006.GI8956@redhat.com>

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


  reply	other threads:[~2019-06-05 20:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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é

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190605201335.GD22416@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.