lkml.org 
[lkml]   [2012]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL] KVM updates for the 3.4 merge window
From
Date
On Tue, 2012-03-20 at 16:08 +0200, Avi Kivity wrote:
> Linus, please pull from
>
> ra.kernel.org:/pub/scm/virt/kvm/kvm.git kvm-updates/3.4
>
> (ssh URL as git.kernel.org is down at the moment) to receive the KVM
> updates for the 3.4 merge window. Changes include timekeeping
> improvements, support for assigning host PCI devices that share
> interrupt lines, s390 user-controlled guests, a large ppc update, and
> random fixes.

I wonder if Linus missed this one ... :-)

But that's not the point of the email ... Avi, I have a bit of a problem
with the way you manage your tree(s).

It appears to me that you have on one side, a tree that has all of KVM
dev. history for years, which is used as a parent by your
sub-maintainers such as Alex, and as your main dev. tree. However, that
-tree- is not related to Linus, and whenever you do a pull request, you
basically rebase patches on top of a different tree which is derived
from Linus.

That means that everything gets constantly rebased, and it makes life
very much harder for us working with this.

For our own dev, we have to essentially work on trees that derive from
Linus, my own -next branch, Alex's -next branch, whatever you have going
on etc... and updating/rebasing our own local WIP patches is extremely
painful because there is never a recent common ancestor between your
trees (and other deriving from it such as Alex) and anything else.

Is there any reason why you keep working that way other than a bad
habit ? :-)

It would be much easier for everybody involved if your WIP development
was always based on a recent ancestor and that you did not rebase it,
meaning that Linus would just "pull" it and everybody would resync
cleanly after every merge window.

Cheers,
Ben.




\
 
 \ /
  Last update: 2012-03-23 01:13    [from the cache]
©2003-2011 Jasper Spaans