[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: linux-2.6-xen et al

  • To: "Chris Wright" <chrisw@xxxxxxxxxxxx>
  • From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
  • Date: Wed, 7 Jun 2006 11:31:34 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, quintela@xxxxxxxxxx
  • Delivery-date: Wed, 07 Jun 2006 03:31:56 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qh/g6ZqspKBvVs3lDbHZwbQSHuNLsQdZQZpnZz3rZLKKo57M2ASLmRa9OuySYJPY2WgsUS9ki3iy+7AnHB/L5cKHsCaormsWn1SQpPo2sJs9LRxHe9zQDNFqpaXi15ClRpDfEsDyMQ2jS93bLtxIlqV8roAP60wcw2KFaGHXVnc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 6/5/06, Chris Wright <chrisw@xxxxxxxxxxxx> wrote:
Going from xen-unstable to linux-2.6-xen is largely scripted (although
it needs human attention).  The rest of the merging is automated to the
degree that SCM's can help, final bit of conflict resolution being
manual, of course.

Yes, it's pretty much automated now, all I do is sanity check the
result before it goes out.  There's a few corner cases which can cause
- add/delete of files to the sparse tree:
 * add can be dropped iff the file is added first and only changed in
a seperate changeset
 * delete needs to restore the file to the unchanged version
- merges and long lived branches:
 Since the process linearizes the changesets, merges can usually be
dropped (unless they sneak in changes...)  This becomes a bit tricker
with long lived branches, especially when there are merges back from
xen-unstable -- we have those regularly in the xen-unstable-ia64 tree
and try to avoid them otherwise.
- 2.6.16 vs differences:
 xen-unstable is based on while linux-2.6-xen is based on 2.6.16


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.