Re: [PATCH] Config.mk: update OVMF changeset

From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] Config.mk: update OVMF changeset
Date: Fri, 23 Oct 2015 13:56:31 +0100	[thread overview]
Message-ID: <1445604991.2374.153.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1510231334560.15801@kaball.uk.xensource.com>

On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:
> > We have no existing stable baseline for that arch, and no testing or
> > reason to believe that cb9a7eb (the Config.mk version currently
> > referenced by 4.6) as being any good at all on that platform,
> > whether we backport a couple of fixes to it or not.
> 
> It is true that ovmf arm64 is not in osstest, but I ran the test
> manually and I know that cb9a7eb plus the one backport works, which is
> just a build fix. In addition the original work for arm64 support was
> done far earlier than cb9a7eb.

20% of the patches since then are ARM related and I'm not sure that a quick
smoke test is a high enough bar to add something in a stable point release
(it might suffice for adding to the development branch and subsequently
releasing, after plenty of time and -rc's, test days etc)

> > I'm not convinced that taking some arbitrary old (although not as old
> > as I
> > thought) OVMF tree which we have tested to our satisfaction and
> > released on
> > x86, slapping a couple of arm64 backports on it and saying "this is now
> > a
> > good and stable thing to use on arm64" makes it good enough to release
> > as
> > ovmf arm64 in 4.6.1, encouraging our users to go about using etc.
> > 
> > Far better to be honest about it for now and point arm64 users at a
> > more
> > bleeding edge ovmf release outside of our own stable releases and
> > prepare
> > to do something better in 4.7.
>  
> Are you suggesting we don't create an OVMF branch for 4.6 until the
> first backport request comes along which we think is appropriate, then
> we decide what to do?  I would rather have an OVMF branch for 4.6 now,
> even if it is just cb9a7eb with no backports.

I'm not against having an OVMF branch ready for any potential bug fixes
which might crop up in the feature set we released and in future we should
probably create one as a matter of course as part of branching.

What I don't like is adding OVMF/arm64 as a new feature in a point release
with very little of the usual confidence we would have in something we
would add in a 4.6.0, let alone a 4.6.1.

Ian.