Re: Xen 4.6, OVMF and arm64

[Wei Liu <wei.liu2@citrix.com>]

On Wed, Oct 14, 2015 at 02:04:48PM +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Wei Liu wrote:
> > On Wed, Oct 14, 2015 at 01:55:39PM +0100, Stefano Stabellini wrote:
> > > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > > On Wed, 2015-10-14 at 12:29 +0100, Wei Liu wrote:
> > > > > I can send a patch for Config.mk when the patch passed our tests.
> > > > 
> > > > For xen-unstable I think we should just move up to
> > > >  http://xenbits.xen.org/gitweb/?p=osstest/ovmf.git;a=shortlog;h=refs/heads/xen-tested-master
> > > > 
> > > > We don't have any separate tests for ovmf in 4.6 (since there is currently
> > > > no correpsonding git branch to even test, I think) so the only way to
> > > > trigger those would be to backport a Config.mk change (again, I think).
> > >  
> > > Maybe we should have a separate tree/branch for ovmf 4.6? What if a bug
> > > is found?
> > 
> > In theory we can. But OVMF doesn't make release so this tree / branch
> > would be hard to manage. EDK (UDK?) makes release, but we don't know yet
> > how it's managed, and we don't know whether OVMF developer care about
> > those releases enough to backport their fixes.
> 
> Couldn't we choose a baseline, for example
> cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, then backport to it any
> commits, or fixes that  we deem necessary?

Yes, that's possible but the implication needs to be considered
carefully.

Up until now we depend on upstream to fix bugs and then update our own
tree, and then respective patches propagate to our tree, and then we ask
for backport of Config.mk update to propagate the fix to stable
branches.  This scheme has minimal workload  for us.

Choosing an arbitrary commit as baseline would mean we don't actually
get support from upstream (I don't think anyone would be interested in
helping maintaining a arbitrary fork, just think about someone who forks
xen.git at arbitrary commit and asks for fix for issue). In the long run
this might cause us problem, too much maintenance burden -- considering
each Xen stable release needs to be maintained for an extended period of
time and OVMF is a fast moving target.

Wei.