ARM branch maintenance proposal

Andy Whitcroft apw at
Thu Aug 12 17:13:24 UTC 2010

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.



More information about the kernel-team mailing list