OSSTest OVMF pushgate

OSSTest OVMF pushgate

[Wei Liu]

Ian and Ian,

Currently OSSTest pushes OVMF changesets to osstest/ovmf.git, while
xen.git references ovmf.git. This requires us to do manual push from
osstest/ovmf.git to ovmf.git.

I would like to just reference master in Xen's Config.mk.  I suppose we
should make OSSTest to push to both ovmf.git and osstest/ovmf.git to
avoid having a stale osstest/ovmf.git tree. But I'm not quite sure what
needs to be done.

Wei.

Re: OSSTest OVMF pushgate

[Ian Campbell]

On Wed, 2015-02-25 at 17:20 +0000, Wei Liu wrote:
> Ian and Ian,
> 
> Currently OSSTest pushes OVMF changesets to osstest/ovmf.git, while
> xen.git references ovmf.git. This requires us to do manual push from
> osstest/ovmf.git to ovmf.git.
> 
> I would like to just reference master in Xen's Config.mk.

This will make the ovmf version used by xen.git be directly tied (via a
push gate) to commits made upstream. We do not currently have anything
like this.

e.g. for qemu we have qemu-mainline tests but xen.git points to output
the qemu-upstream-unstable push gate, where the input is maintained by
Stefano pushing things to a staging branch.

I think tracking upstream from xen.git is likely to be fine for
something like ovmf, but I wanted to make sure this was understood.

We may need to take special care during freeze periods, i.e. by
switching back to a specific version during the freeze. Or else we risk
getting an unfortunate ovmf push right as we try and release.

>   I suppose we
> should make OSSTest to push to both ovmf.git and osstest/ovmf.git to
> avoid having a stale osstest/ovmf.git tree. But I'm not quite sure what
> needs to be done.

I think we shouldn't remove one of the trees so as to avoid breaking
peoples URLs, but they should have the same content, so I think we
should make osstest/ovmf.git a symlink to ovmf.git.

Here is a possible sequence of events, although you will want Ian to
validate I think:

        First we should pause the ovmf gate, by dropping a stop file in
        the right place.
        
        Then we should make the contents of the two trees the same, in
        particular make sure that tags etc are in sync, then make the
        link.
        
        Then set the master branch of the single ovmf.git to point to
        the current value of OVMF_UPSTREAM_REVISION.
        
        Then commit a patch to xen.git/Config.mk which changes
        OVMF_UPSTREAM_REVISION to "master" and wait for that to pass
        through the test gate.
        
        Then push a change to osstest.git#ap-push to push to master and
        not xen-tested-master and wait for that to pass the gate (or
        force push, since the gate won't be testing it anyway)
        
        Then restart the ovmf gateway, which will use the new master as
        its baseline I think.

Re: OSSTest OVMF pushgate

[Wei Liu]

On Tue, Mar 03, 2015 at 04:39:39PM +0000, Ian Campbell wrote:
> On Wed, 2015-02-25 at 17:20 +0000, Wei Liu wrote:
> > Ian and Ian,
> > 
> > Currently OSSTest pushes OVMF changesets to osstest/ovmf.git, while
> > xen.git references ovmf.git. This requires us to do manual push from
> > osstest/ovmf.git to ovmf.git.
> > 
> > I would like to just reference master in Xen's Config.mk.
> 
> This will make the ovmf version used by xen.git be directly tied (via a
> push gate) to commits made upstream. We do not currently have anything
> like this.
> 
> e.g. for qemu we have qemu-mainline tests but xen.git points to output
> the qemu-upstream-unstable push gate, where the input is maintained by
> Stefano pushing things to a staging branch.
> 
> I think tracking upstream from xen.git is likely to be fine for
> something like ovmf, but I wanted to make sure this was understood.
> 

Yes, that is my intent.

I was thinking it might be better for xen-unstable developers to always
get our tested version to start with, so that they get a tree that at
least usable and has all the good stuffs up the our tested head.

I'm fine with model like qemu-upstream-unstable too. If we want to
achieve the same effect that might involve quite a bit of manual
pushing.

> We may need to take special care during freeze periods, i.e. by
> switching back to a specific version during the freeze. Or else we risk
> getting an unfortunate ovmf push right as we try and release.
> 

Yes.

Wei.

> >   I suppose we
> > should make OSSTest to push to both ovmf.git and osstest/ovmf.git to
> > avoid having a stale osstest/ovmf.git tree. But I'm not quite sure what
> > needs to be done.
> 
> I think we shouldn't remove one of the trees so as to avoid breaking
> peoples URLs, but they should have the same content, so I think we
> should make osstest/ovmf.git a symlink to ovmf.git.
> 
> Here is a possible sequence of events, although you will want Ian to
> validate I think:
> 
>         First we should pause the ovmf gate, by dropping a stop file in
>         the right place.
>         
>         Then we should make the contents of the two trees the same, in
>         particular make sure that tags etc are in sync, then make the
>         link.
>         
>         Then set the master branch of the single ovmf.git to point to
>         the current value of OVMF_UPSTREAM_REVISION.
>         
>         Then commit a patch to xen.git/Config.mk which changes
>         OVMF_UPSTREAM_REVISION to "master" and wait for that to pass
>         through the test gate.
>         
>         Then push a change to osstest.git#ap-push to push to master and
>         not xen-tested-master and wait for that to pass the gate (or
>         force push, since the gate won't be testing it anyway)
>         
>         Then restart the ovmf gateway, which will use the new master as
>         its baseline I think.
>