Re: [Qemu-devel] Deprecation policy and build dependencies

[Eduardo Habkost]

On Mon, Jun 03, 2019 at 08:16:29PM +0200, Cornelia Huck wrote:
> On Mon, 3 Jun 2019 14:02:16 -0400
> John Snow <address@hidden> wrote:
> 
> > On 6/3/19 8:26 AM, Markus Armbruster wrote:
> > > John Snow <address@hidden> 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