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

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

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 defconfig |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/defconfig b/defconfig
index b4ed94d..c2bc251 100644
--- a/defconfig
+++ b/defconfig
@@ -22,7 +22,7 @@ DESTDIR=dist
 #GRUB_URL="http://git.savannah.gnu.org/r/grub.git"
 #LIBVIRT_URL="https://gitorious.org/libvirt/libvirt.git"
 XEN_URL="git://xenbits.xen.org/xen.git"
-QEMU_URL="git://git.qemu.org/qemu.git"
+QEMU_URL="git://xenbits.xen.org/qemu-upstream-unstable.git"
 QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-unstable.git"
 SEABIOS_URL="git://xenbits.xen.org/seabios.git"
 GRUB_URL="git://git.savannah.gnu.org/grub.git"
@@ -33,9 +33,9 @@ LINUX_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git"
 # Software versions.
 XEN_REVISION="master"
 QEMU_REVISION="master"
-QEMU_TRADITIONAL_REVISION="master"
-SEABIOS_REVISION="master"
+QEMU_TRADITIONAL_REVISION="3b45fcf0c163b9cff4d8115f7b75b42918a9b1b5"
+SEABIOS_REVISION="rel-1.8.0"
 GRUB_REVISION="master"
 LIBVIRT_REVISION="master"
-OVMF_REVISION="master"
+OVMF_REVISION="a065efc7c7ce8bb3e5cb3e463099d023d4a92927"
 LINUX_REVISION="master"
-- 
1.7.10.4

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

[George Dunlap]

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.

 -George

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

[Stefano Stabellini]

On Tue, 12 May 2015, 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.

I agree that from Raisin's point of view is not great, but the default
URLs and some of the default REVISIONs are needed by OSSTest.
The only alternative I could think of would be creating a separate git
repo for the default configs.

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

[Ian Campbell]

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.

Stefano, I think it would be good to also import the little comment
snippet associated with the manually maintained revisions in Config.mk.

For the other branches Config.mk automatically tracks the outputs of the
various osstest push gates. It looks like raisin's defconfig already
mostly does that.

I think we should consider whether for libvirt raisin should be using
git://xenbits.xen.org/libvirt.git#xen-tested-master by default.

We should also consider for linux whether to use our tested tree on
xenbits, but I think that is less likely to be desirable.

BTW, the canonical URL for Linus' tree is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git not
what is currently in defconfig.

Ian.

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

[George Dunlap]

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

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

[Stefano Stabellini]

On Tue, 12 May 2015, George Dunlap wrote:
> 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.

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.

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

[Ian Campbell]

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.

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

[Stefano Stabellini]

On Tue, 12 May 2015, 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.
> 
> Stefano, I think it would be good to also import the little comment
> snippet associated with the manually maintained revisions in Config.mk.

OK


> For the other branches Config.mk automatically tracks the outputs of the
> various osstest push gates. It looks like raisin's defconfig already
> mostly does that.
> 
> I think we should consider whether for libvirt raisin should be using
> git://xenbits.xen.org/libvirt.git#xen-tested-master by default.

Sounds like a good idea


> We should also consider for linux whether to use our tested tree on
> xenbits, but I think that is less likely to be desirable.

The Linux tree tested by osstest is based on 3.14, a bit too old for
raisin, I think.


> BTW, the canonical URL for Linus' tree is
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git not
> what is currently in defconfig.

I'll fix it