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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 05/12/2015 10:42 AM, Ian Campbell wrote:
> On Tue, 2015-05-12 at 10:25 +0100, George Dunlap wrote:
>> On 05/12/2015 10:16 AM, Stefano Stabellini wrote:
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>
>> What's the purpose of doing this?  In particular it seems like having to
>> manually update the changesets as we go along is going to be a big pain
>> in the neck.  There shouldn't be a need to keep raisin.git and xen.git
>> in such close synchrony.
> 
> The intent is to replace the tracking we currently do in xen.git with
> tracking in raisin.git, not to keep the two in sync. It'll have to run
> alongside until we actually remove that stuff from xen.git though.
> 
> For example, we do not want to just track seabios master, that is a
> development version. I (as maintainer) want to track seabios releases
> which are tested against Xen, especially for a release.
> 
> OVMF and qemu-trad are also similarly managed in Config.mk.

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.

 -George