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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 5 May 2015, Ian Jackson wrote:
> 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 am on it.


> > > 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 understand what you meant now, thanks.


> 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'.

raisin does not have a list of trees, if not in the form of a default
config file provided for users' convenience. Theoretically
ts-raisin-build could use the default config and grep _URL
raisin/defconfig, but I think it would be uglier than the current
approach.

Keep in mind that with raisin there is no hidden git cloning of external
trees. Not at all. All the trees are specified in the config file and
cloned explicitly. Actually I think that it is nice and natural for
ts-raisin-build to specify a list of URLs, because ts-raisin-build also
wants to specify which components raisin is supposed to build and there
is a 1:1 relationship.

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