Re: [Xen-devel] [OSSTEST] Add a flight to test qemu.org's ("mainline") master branch.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-05-02 at 12:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[OSSTEST] Add a flight to test qemu.org's ("mainline") 
> master branch."):
> > I did consider causing make-flight:job_create_test_filter_callback
> > to omit any test which didn't use qemuu but I decided not to because
> > it is used for PV qdisk backends too. (and now I'm wondering why the
> > same doesn't apply to the qemu-upstream flights too)
> 
> Thinking about this since my last message, it occurs to me that it
> isn't in general easy for make-flight to know when qemuu is going to
> be used.  After all xl may decide on a whim to change which qemu it
> uses for complicated reasons.  I'm not really sure where that thought
> is leading.

Perhaps the answer is not to worry to much about a few pointless jobs in
these flights. Especially given that qemuu+seabios is mostly the
default.

> > I'm not sure what to call the output of the push gate on xenbits to
> > be not confusing, git://xenbits.xen.org/osstest/qemu.git is a
> > placeholder. The XXX should be removed before committing. I wondered
> > about suggesting moving all of the push gates which aren't actually
> > intended for end user consumption (but rather for osstest
> > book-keeping) under e.g.  git://xenbits.xen.org/osstest-gated, that
> > would be the libvirt tree, the linux trees which linux-linus and
> > linux-next push to, this new tree, perhaps others.
> 
> There are big git performance advantages to having all of these things
> be refs in the same git tree as the non-osstest-related branches for
> whatever it is.

True. Which of the many qemu trees should this flight deal with then? I
suppose qemu-xen-upstream-unstable (or whatever the xen-unstable branch
of qemuu is called) is the correct one?

> And I'm not sure it's right to say these aren't "for end user
> consumption".  I don't see why someone couldn't use one of our tested
> branches if they felt like it.  Of course some of them are better than
> others and they aren't very well documented.

This is a good point I suppose. We also reserve the right to move,
remove or just stop updating these trees though, without warning.

> The arrangement with the zillions of qemu trees on xenbits is
> anomalous (and should probably go away eventually).

Can we sort that for 4.5?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel