Re: [PATCH 00 of 10] blkfront pvops updates

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 04/29/2010 04:05 PM, Daniel Stodden wrote:
> On Thu, 2010-04-29 at 17:36 -0400, Jeremy Fitzhardinge wrote:
>   
>> On 04/29/2010 02:28 PM, Daniel Stodden wrote:
>>     
>>> So I'm probably building the wrong tree by default.
>>>
>>> I used to make linux-2.6-pvops when starting to work.
>>> Which checks out xen/master.
>>>
>>> How does this relate?
>>>   
>>>       
>> xen/master is an alias for xen/stable-2.6.31.x at the moment.  I just
>> submitted a patch to make this switchover explicit, and will move it to
>> 2.6.32 soon.
>>     
> Okay, so xen/master rather defaults to some stable tree.
>
> If xen/frontend is the topic branch, people ideally prepare patches per
> topic, and trunk is rather xen/next, then the thing I still don't follow
> is than xen/frontend hasn't been merged since
>
> * commit 8800a1de3df00fa994f72ad0d7c1eda9b5a0b514
> | Author: Paolo Bonzini <pbonzini@redhat.com>
> | Date:   Wed Jul 8 12:27:37 2009 +0200
>
> Why would I want to build a kernel derived from last July's state? Or,
> put differently: Is it okay to merge these topic branches before
> anything else?
>   

My usual workflow is:

   1. Develop some patches on xen/next, until they work
   2. Rebase those patches onto a topic branch
   3. Merge that topic branch onto xen/next

This is necessary because an individual topic branch isn't necessarily
compilable into a working kernel (though they should always compile).

The topic branches are often based on very old kernel versions, and I
avoid rebasing or merging new kernels into them for as long as
possible.  This is so that they will share a common base version with
any other branch I want to merge them into (including mainline Linux),
so that 3-way merging is most likely to work.

It gets awkward if xen/next has other changes which conflict with the
topic branch either because some other piece of necessary infrastructure
is missing, or just plain merge conflicts.  If they're minor then I
resolve them in the merge to xen/next (git rerere is your friend for
remembering these kinds of conflict resolutions).   But if there's some
major subsystem change, then I'll update the topic branch by merging in
an appropriate branch to update the branch (ideally always from the
mainline Linux branch, or from another Xen topic branch).

    J