Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > > taking them
> > > > are explained in the referenced thread.
> > 
> > That explanation isn't very convincing to me.
> > 
> > > I cannot believe we are going to move forward without a way to
> > > introduce
> > > any OVMF fixes into the  stable branches.
> > 
> > It is fine to introduce OVMF fixes into stable branches, of course.
> > 
> > But it is not fine to introduce other upstream changes to OVMF,
> > willy-nilly.
> > 
> > Obviously these two requirements cannot be satisfied without there
> > being some branch of OVMF which contains the intended fixes, without
> > the unwanted upstream development.
> 
> For things which we released as part of a stable release I completely
> agree.
>
> But OVMF for aarch64 was not part of the 4.6 release.

What I asked is only one of the backports that might present themselves
in the future. Even if the backport request is rejected, I think we
should create an OVMF branch for 4.6 anyway.


> 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.


> 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel