[android-kernel] Linaro and common- tree
andy.green at linaro.org
Thu Oct 6 02:07:38 UTC 2011
On 6 October 2011 02:36, Tim Bird <tim.bird at am.sony.com> wrote:
> On 10/05/2011 08:37 AM, Andy Green wrote:
> > Another side-issue is we are also looking at refactoring the
> > Androidization patchset into topic branches, at the moment they're kind
> > of reflecting the history that they were applied on plus or minus some
> > munging around. So, all the net core patches for example would be
> > together in one series, then all the wireless ones in a series on top of
> > that, etc. It seems they would be easier to maintain then, opinions on
> > that approach are also welcome.
> I've been working on a set of broken-out Android patches, in quilt format,
> with exactly the same goal. It's much easier (at least for me) to maintain
> differences as distinct patches using quilt, rather than as a series (or
> of branches) of git commits.
> But possibly I'm just missing how to do this easily with git.
> I would very much like to compare approaches, and possibly share
Thanks a lot for the reply Tim. I can describe how I manage this flow in
detail. Actually, since we would interact through pure git, it's not
necessary to unify the patch management scheme to be able to cooperate. But
since I spent so much time on exactly this subject I guess we both find it
interesting to describe it.
There are a number of valid ways to come at managing the topic patchsets and
quilt is certainly one of them. Another approach that would work is to use
git cherry-pick to throw around series of patches from one branch to
another. The way I have been using though is stgit.
stgit has the advantages of quilt in terms of managing itself the members of
the series. If you try to do it with git cherry-pick, you have to have
explicit secondary branches floating around to take the series from and keep
tracking of what came from where and what basis it was on, etc, it doesn't
seem it will scale well to dozens of topic and multiple branches. stgit has
a further characteristic that it stores applied / pushed patches from the
series in absolutely pure git commits, so at any time you can push what you
have to remote git and that's exactly what people will pull with no stgit on
their side. Stgit is like quilt in terms of patch stack operation, push,
pop, float, "goto", support for rebase, re-ordering, apply conflict
management, import, export, mail and so on. Stgit series, what is and is
not applied, all state in fact, is bound to a specific git branch. So when
you checkout a different branch in git, the stgit context for that branch is
made active and nothing is lost about stgit in the previous branch. In that
way, it's like some extra features integrated on top of git.
Here's a tree I maintain with many topic branches using that flow
if you go back through the gitweb history, you can see it is formed from a
set of other tracking-topic- branches each rebased on top of each other. I
have a set of scripts to automate this rebasing. If I have something to fix
or change at tracking-topic-hdmiaudio for example, I would move to that
branch, change or add patches there, build and confirm the kernel works at
that patchlevel, then use my scripts to rebase the topic branches on top of
it, confirm we didn't break anything, and push the changed branches to
The main downside is management by stgit is slow. I have a fast build
machine but stgit just uses one thread and favours correctness over speed,
it's constantly checking to see if any files were changed behind its back in
the tree for example. Fully rebasing all my trees is a matter of 90
minutes, although that includes a bunch of special rebase trees that are
different from what we're discussing.
The most important characteristic with managing the series at each topic
level is that the topic patch series must strictly be sitting purely on top
of the basis. git rebase, another candidate for handling the topic series,
depending on the relationship of the two trees, will not always provide that
feature in my experience.
> the workload of maintaining such a thing.
That's great we have had the same thoughts looking at the same situation.
What I am expecting is we get an easy ride until Linus kernel 3.1 release,
at which point a backlog of disruptive patches will be applied to Linus HEAD
for 3.2-rc0 and there is some work to do. We should keep in contact and
figure out how to react to it when the extent of it is known. If it's
reasonable amount of work I can take care of it, if it's getting a bit much
it will be really great to be able to figure out how to share the load.
Something else to consider about refactor scheme is when an official
common-3.2 is coming say at 3.2-rc7. Unless we are able to interest common-
maintainers in our scheme, that will not be structured according to our
refactor. I gave this some thought, the worst that can happen is we have to
discard the refactor and just take common-3.2 when the tracking basis is the
same; consumers of the Androidization tree won't notice anything. More
likely though, a large proportion of topic patches in, say, net core area
are going to be unchanged or have minor tweaks. In that case, if we make
sure that our tree and this first common-3.2 are on the same basis version,
it should be possible to pick and adapt common-3.2 content on to the
refactor and crucially, use git diff to confirm that the resulting tree is
100% identical at that point. So we can be certain that we have everything
imported perfectly from the common- update even though the series is
completely different. Thereafter, we can pick new patches going on
common-3.2 one by one into the refactored tree. So, I think that case is
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev