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 02:01 -0600, Jan Beulich wrote:
> > > > > On 22.10.15 at 19:08, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> > > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > > changeset"):
> > > > On Thu, 22 Oct 2015, Ian Campbell wrote:
> > > > > This was discussed prior to Wei submitting this patch, but I can't
> > > > > remember
> > > > > the reference. Hopefully either Wei or Stefano does.
> > > > 
> > > > 1444832748.23192.213.camel@xxxxxxxxxx 
> > > 
> > > Thanks for the reference.
> > > 
> > > I'm quite uncomfortable with this, really.
> > > 
> > > People who are using xen.git stable branches ought to get only changes
> > > that we (or perhaps, someone else whose judgement we have some reason
> > > to trust) have intentionally decided are suitable for deployment as a
> > > bugfix or security update in an existing installation.
> > > 
> > > Ie, changes in stable branches are supposed to be low risk.  That's
> > > not compatible with tracking an upstream development branch.
> > 
> > FWIW, I agree. Do we know of specific commits that we actually
> > need?
> 
> Yes. Those (that?) and the reasons why we aren't just trivially taking them
> are explained in the referenced thread.
> 
> Really this is about adding a new feature (arm64 support for ovmf) into
> 4.6.1 for Raisin's benefit.

This is not just about Raisin. What's going to happen when we fix a bug
in OVMF (http://marc.info/?l=xen-devel&m=144552787020580) which we think
needs to be backport to 4.6?

I cannot believe we are going to move forward without a way to introduce
any OVMF fixes into the  stable branches.


> My personal preference, given the arguments made in the thread, would be
> for raisin to just point at mainline ovmf for the arm64 case. IOW
> acknowledge that arm64 ovmf was not actually part of the 4.6 release and
> that we should work towards making it not a special case in the 4.7 release
> (by, you know, testing it prior to release and things like that).

Let's now lose the focus of the conversation by talking about this
specific backport request. We can always find ways around this in
Raisin.

The real problem is: what are we going to do about backport requests for
OVMF in general?

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