|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/9] raisin: add a component to build qemu_traditional
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/9] raisin: add a component
to build qemu_traditional"):
> On Thu, 16 Apr 2015, Ian Campbell wrote:
> > But can I _query_ what it is able to build (i.e. the components the
> > current version supports) and/or what it would actually build if asked
> > (i.e. the revisions of things).
>
> If by query you mean issuing an XML-RPC request, the answer is no :-)
Obviously that would be a stupid syntax to use.
> All the components are listed in the config file as URLs and REVISIONs,
> they also have a component script each, so a single "ls components" will
> tell you which components raisin can build. grep _REVISION config will
> tell you which versions are going to be built. Nothing will be
> automatically built unless it has a _REVISION entry in the config file.
> Commenting out a _REVISION entry is a good way to disable the build of
> a component.
>
> Each component is independent and there is no knowledge about versions
> of one component (xen 4.5 and earlier) needing one or more versions of
> another component (qemu-traditional). The main idea was that the
> versions or tags would be supplied by the user. Maybe there should be?
> That would increase the complexity though.
Perhaps we should have some `user stories'.
Alice wants to build Xen mainline. She reads the wiki and reads
about raisin. She does git clone git://somewhere/raisin.git, cd
raisin, ./raise xen unstable. `raise' automatically arranges to
clone and build everything needed.
And a more complicated one:
Bob is running Xen 4.5 as supplied by Debian. He reports a bug which
gets forwarded upstream. Carol, the upstream maintainer, asks Bob to
try to reproduce the bug with vanilla 4.5 with a patch applied.
Carol points Bob at raisin and at her patched xen.git. Bob does git
clone git://somewhere/raisin.git, cd raisin, edits the raisin
configuration for Xen 4.5 to specify Carol's url, and runs ./raise
xen 4.5. `raise' automatically arranges to clone and build
everything needed. Bob takes feeds the generated hypervisor .deb to
dpkg -i, reboots, and collects the data requested by Carol.
New subtrees:
David is adding a feature to Xen which depends on an external project
`wombat'. After David's changes, the Xen toolstack will need
wombat to be installed on the dom0. David creates a suitable wombat
branch and tree, and sends patches as follows:
- raisin: determine somehow (from the xen version? from
the contents of xen.git? statically?) whether wombat is
needed
- xen.git: toolstack code to run installed version of wombat
- osstest: introduce a push gate for wombat, and plumb its
git url and git revision through cr-daily-branch and make-flight
After David's patches are applied, Alice's builds pick up wombat
automatically, and osstest knows how to specify and record the
version of wombat to use whenever necessary. Bob's build of 4.5
is unaffected.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |