[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Stefano Stabellini writes ("Re: [PATCH] OSSTEST: introduce a raisin build 
> 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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.