Re: [Xen-devel] [PATCH] OSSTEST: introduce a raisin build test

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Stefano Stabellini writes ("Re: [PATCH] OSSTEST: introduce a raisin build 
test"):
> I agree that revisions should be passed to ts-raisin-build by osstest,
> as Ian suggested. AFAICT that should be enough to meet all your
> criteria.

You also need to call store_revision for all the trees involved, as
Ian C says.

> > I'm not a huge fan of the way that your current patch hardcodes the
> > list of subtrees in ts-raisin-build.  I don't see any logical reason
> > why ts-raisin-build would need to know this, if raisin could be
> > persuaded to print it.
> 
> I am not sure I understand what you mean here. Yes, revisions are
> hardcoded and that is a mistake, but trees are not.  This is a snippet
> from ts-raisin-build:
> 
>     echo >>config XEN_URL=\\"$r{tree_xen}\\"
>     echo >>config QEMU_URL=\\"$r{tree_qemuu}\\"
>     echo >>config QEMU_TRADITIONAL_URL=\\"$r{tree_qemu}\\"
>     echo >>config SEABIOS_URL=\\"$r{tree_seabios}\\"
>     echo >>config LIBVIRT_URL=\\"$r{tree_libvirt}\\"
>     echo >>config OVMF_URL=\\"$r{tree_ovmf}\\"
> 
> None of the trees are hardcoded, they are all passed to ts-raisin-build
> by osstest using tree_* variables, as you suggested above.
> What am I missing?

The _list of trees_ is hardcoded.  That is, your ts-raisin-build
contains (an expanded form of) the list qw(xen qemuu qemu seabios
libvirt ovmf).

I was suggesting ts-raisin-build could contain just 1. a call to raise
to list all the relevant trees 2. an iteration over the output,
copying information to/from runvars, 3. an exception table to allow
for situations like 'QEMU' ne uc 'qemuu' and 'QEMU_TRADITIONAL' ne uc
'qemuu'.

Ian.

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