Re: [PATCH] raisin: update defaults according to the current content of Config.mk

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-05-12 at 12:31 +0100, Stefano Stabellini wrote:
> > But wrt raisin, does it make sense to have the specific changesets we're
> > looking at mixed in with the updates to raisin itself, particularly in
> > its infancy, where the functionality will be in flux quite a bit?
> > 
> > If xenproject.org has a libvirt.git with a "xen-tested-master", would it
> > make sense to have something similar for all the other repos?  Perhaps
> > with "xen-tested-${version}-master" for specific releases?
> > 
> > Making raisin just the build tool, and storing the "build this version
> > with this version" somewhere else (like in xenbits git branches) makes
> > more sense to me.
> 
> I am OK either way, but I agree that would be cleaner to have the
> versions stored somewhere else. I would go for a separate git
> repository, with just the configs.

I would expect that many real (as opposed to automated )users of raisin
would want some easy way to build e.g. Xen 4.6 along with all the
versions of the various components which were tested as part of that
release. e.g. something equivalent to what was in the release tarball.

Likewise for the development version I'd expect that they would want
some way to ask for something which had undergone some minimal testing
rather than the very most bleeding edge stuff, similar to choosing
xen.git#master rather than xen.git#staging.

Having to go and get that from a separate tree, or worse to construct
that config file themselves, would be a usability barrier to those users
IMHO.

Ian.