Re: [Xen-devel] OVMF related osstest failures on multiple branches

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.01.16 at 16:28, <ian.campbell@xxxxxxxxxx> wrote:
> Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
> does seem to have worked (i.e. the flight hasn't actually finished yet but
> it has passed the debian-hvm-install step).
> 
> We have in the past, after much discussion[0], backported changes to
> Config.mk:OVMF_UPSTREAM_REVISION to pull forward wholesale to a newer ovmf.
> 
> On another (more recent) occasion there have been strong objections to
> doing so[1]. I think we concluded there that we should add stable-X.Y
> branches to git://xenbits.xen.org/ovmf.git and cherry-pick fixes, the
> reason nothing happened then was that the backport in question was a
> feature request for ovmf on arm64 which is not something we test and was
> not therefore something I was comfortable with.
> 
> If we consider [0] as precedent then we would want to backport
> xen.git 04c5efb0a141 and f046e501bbc to staging-4.4, -4.5 and -4.6 to bring
> those branches up to ovmf.git 52a99493cce8.
> 
> If we want to follow [1] then the plan of attack is:

I'm afraid I can't easily build an opinion which of the two is the
lesser evil. I guess as long as we consider OVMF use experimental
(do we?), following [0] would be the slightly more natural approach.

Jan

>  * I need to identify the patch(es) which actually fix this issue and
>    cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
>  * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
>    stable branches to point to all those commits (either branch name or
>    SHA, not sure).
>  * The release checklist needs updating to include tagging this new tree
>    and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
>    commit (I think this is strictly speaking option, but we should do it).
>  * We might want to consider retroactively tagging the versions of ovmf
>    used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
>    helpful for people using gitk etc to look at the history I suppose 
> 
> That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
> manual Config.mk update, if we were to switch to a gate it would be
> different but regardless of the merits of doing things that way it does't
> seem like a thing to do on a stable branch.
> 
> Ian.
> 
> [0] 
> http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04428.html 
> [1] 
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02381.html 
>  stemming from
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01534.html 




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