From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH 4/9] raisin: add a component to build qemu_traditional Date: Thu, 16 Apr 2015 12:15:20 +0100 Message-ID: <21807.39368.850533.692733@mariner.uk.xensource.com> References: <1429110900-8286-4-git-send-email-stefano.stabellini@eu.citrix.com> <552E832A.9020900@citrix.com> <552E8870.6020302@citrix.com> <1429113529.15516.344.camel@citrix.com> <21806.36527.622876.472825@mariner.uk.xensource.com> <1429115186.25195.9.camel@citrix.com> <1429173926.25195.30.camel@citrix.com> <1429179039.25195.60.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: george.dunlap@eu.citrix.com, Andrew Cooper , xen-devel@lists.xensource.com, Ian Campbell List-Id: xen-devel@lists.xenproject.org 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.