Xen devel - Feb 2012 - relation between upstream qemu tree and qemu-upstream-unstable.git

How is the supposedly strait clone on xenbits related to the "real"
tree?
It doesn''t seem to be tracking it, so I''m sort of confused
whether I
could in fact use the upstream tree in favor of the made up mirror.

Thanks, Jan

Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree and
qemu-upstream-unstable.git"):
> How is the supposedly strait clone on xenbits related to the
"real" tree?
> It doesn''t seem to be tracking it, so I''m sort of
confused whether I
> could in fact use the upstream tree in favor of the made up mirror.
AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
but rather one with various other patches needed for Xen.  But Stefano
will be able to comment for sure.

It''s certainly not automatically mirrored from anywhere.  It is (now)
updated only by a test push gate from the corresponding staging tree.

Ian.

On Tue, 7 Feb 2012, Ian Jackson wrote:
> Jan Beulich writes ("[Xen-devel] relation between upstream qemu tree
and qemu-upstream-unstable.git"):
> > How is the supposedly strait clone on xenbits related to the
"real" tree?
> > It doesn''t seem to be tracking it, so I''m sort of
confused whether I
> > could in fact use the upstream tree in favor of the made up mirror.
> 
> AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> but rather one with various other patches needed for Xen.  But Stefano
> will be able to comment for sure.
Hi Jan,
qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
based on qemu-stable-1.0.git, it is going to have many more Xen specific
backports than the upstream stable tree.
In particular I am talking about the QEMU timers, save/restore and PCI
passthrough series.

- Stefano

On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini
wrote:
> On Tue, 7 Feb 2012, Ian Jackson wrote:
> > Jan Beulich writes ("[Xen-devel] relation between upstream qemu
tree and qemu-upstream-unstable.git"):
> > > How is the supposedly strait clone on xenbits related to the
"real" tree?
> > > It doesn''t seem to be tracking it, so I''m sort
of confused whether I
> > > could in fact use the upstream tree in favor of the made up
mirror.
> > 
> > AIUI qemu-upstream-unstable is not a direct copy of the upstream tree,
> > but rather one with various other patches needed for Xen.  But Stefano
> > will be able to comment for sure.
> 
> Hi Jan,
> qemu-upstream-unstable.git is not a mirror of an upstream tree: while it is
> based on qemu-stable-1.0.git, it is going to have many more Xen specific
> backports than the upstream stable tree.
The default rule will be that such patches will be backports though,
right? e.g. backported patches must have already been committed to the
upstream dev branch, somewhat similar to the Linux kernel
stable_kernel_rules.txt?

Ian.
> In particular I am talking about the QEMU timers, save/restore and PCI
> passthrough series.
> 
> - Stefano
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

On Wed, 8 Feb 2012, Ian Campbell wrote:
> On Wed, 2012-02-08 at 11:56 +0000, Stefano Stabellini wrote:
> > On Tue, 7 Feb 2012, Ian Jackson wrote:
> > > Jan Beulich writes ("[Xen-devel] relation between upstream
qemu tree and qemu-upstream-unstable.git"):
> > > > How is the supposedly strait clone on xenbits related to the
"real" tree?
> > > > It doesn''t seem to be tracking it, so I''m
sort of confused whether I
> > > > could in fact use the upstream tree in favor of the made up
mirror.
> > > 
> > > AIUI qemu-upstream-unstable is not a direct copy of the upstream
tree,
> > > but rather one with various other patches needed for Xen.  But
Stefano
> > > will be able to comment for sure.
> > 
> > Hi Jan,
> > qemu-upstream-unstable.git is not a mirror of an upstream tree: while
it is
> > based on qemu-stable-1.0.git, it is going to have many more Xen
specific
> > backports than the upstream stable tree.
> 
> The default rule will be that such patches will be backports though,
> right? e.g. backported patches must have already been committed to the
> upstream dev branch, somewhat similar to the Linux kernel
> stable_kernel_rules.txt?
 
Yes, I meant backports of upstream commits.