ARM branch maintenance proposal

[John Rigby]

On 08/12/2010 11:29 AM, Tim Gardner wrote:
> On 08/12/2010 10:13 AM, Andy Whitcroft wrote:
>    
>> We have classically taken ARM branches as a stack of patches against
>> the base release for Ubuntu and rebased those directly onto the tip of
>> the master branch.  This has allowed us to keep those branches in sync
>> with our master branch by simply rebasing them as master moves forward.
>> This means that Security fixes and general Ubuntu goodness propogate to
>> those branches as they rebase.
>>
>> More recently we have started to receive much more complex source trees.
>> Typically these are based on the target release but they are not simple
>> patch stacks.  They are complex merged trees pulling in changes from
>> multiple sources.  The tip of them representing the required tree.
>> These are not suitable for generating a patch stack from and thus present
>> a maintenance issue.  We have proposed a merge based system to maintain
>> these, whereby the source tree, the Ubuntu master branch, and a packaging
>> branch are merged to generate the result.  This however does impose a
>> new methodolgy on stable maintenance.
>>
>> For other subsystems (such as AppArmor and aufs2) we have yet a third
>> approach.  Here we take the tip if the upstream tree and literally copy
>> over the new files into our tree.  These are then committed as a single
>> commit 'update aufs2 to upstream as at dd-mm-yyyy'.  This has the advantage
>> that we know our tree is exactly the same as the source tree as well as
>> allowing us to maintain the tree in the normal way.  The subsystem and
>> any updates are mearly patches in our stack.
>>
>> I am proposing a new mechanism for maintaining ARM branches, specifically
>> for upstream trees which are very complex and cannot be converted
>> into a patch stack.  For these I propose we adopt the subsystem update
>> model above.  That we convert the delta between the branch tip and the
>> that trees base version into a patch, and apply that patch as normal
>> to the branch.  This allows maintenance of the tree to continue in the
>> normal way, via rebase against the master branch.  When updates to the
>> upstream ARM tree occur we simply can diff the new tip against that
>> taken in the last update and again apply the delta as an update patch,
>> this does require we carefully track our sync points when committing them.
>>
>> Taking the current ARM ti-omap4 update as an example, we have a tree from
>> the vendor which is based on v2.6.35.  We therefore can simply diff the
>> that branch against v2.6.35.  The resulting patch can then be applied to
>> the tip of the master branch.
>>
>>       $ git diff v2.6.35..L29.4>UPDATE
>>       $ git checkout -b temp v2.6.35
>>       $ git apply -C1 --index UPDATE
>>       $ git commit -s -m 'update ARM thingy to SHA1'
>>       $ git rebase origin/master
>>
>> Then we can simply apply the branch packaging and we are ready to upload.
>> For a subsequent updates we would simply diff from the SHA1 recorded
>> above to the tip of the branch and again apply the patch.
>>
>> By taking this approach we do lose the ability to bisect the upstream
>> tree.  But where the upsteam tree needs such bisection we would have to
>> hand generate the trees in order to have the full debian infrastructure
>> in place.  Which is equally easy to do using the original tree, overall
>> not a loss.
>>
>> Comments?
>>
>> -apw
>>
>>      
> This seems like quite a reasonable approach. As package maintainers we
> really don't care that much about the content of the ginormous patch
> that gets the vendor from v2.6.35 to their working tree. We only care
> that the patch exists and that we can easily rebase against _our_ master
> in order to maintain ongoing Ubuntu goodness.
>
> rtg
>    
I like this.  I think it will make my life as the linaro kernel package 
maintainer easier.