Proposal for further openmoko kernel development

[Thomas White]

On Tue, 28 Jul 2009 22:20:44 +0200
Lars-Peter Clausen <lars at metafoo.de> wrote:

> Thus I propose a different development model for future kernel
> development: The basic idea behind this approach is to get rid of the
> centralized development model and go over to a more modular one.
> Instead of having one big monolithic tree containing everything,
> we'll have several subtrees for each driver. On top of that would be
> two machine trees and maybe one for s3c specific patches. The machine
> specific trees would then regularly merge those driver trees they
> need. On top of of the machine trees there would be a combined tree
> where both machine trees get merged. The purpose of this tree is to
> provide a single point which provides everything needed for openmoko
> based devices from where distributions can pull to build their
> kernels.

I'm in favour of such a system.  Some (slightly rambling) observations:

- If we choose to have one branch which spans multiple kernel versions
(i.e. we choose NOT to create a new branch for 2.6.31, 2.6.32, etc),
then I think it would be better to use merges rather than rebases for
updating at each kernel release.  That would give us a complete history
which is bisectable.

[To clarify the meaning of "bisectable":
Rebasing, although it would make the branches look neat in gitk, would
effectively mean that each individual commit in each topic branch no
longer represents a real point in history.  For example, an older
commit which previously could have been tested during a "git bisect"
might no longer even compile because of interactions with the new code
placed beneath its feet by the rebase, fixed in a later commit.  If a
merge were used, history would simply be divided into "pre-merge" and
"post-merge" periods, and the bisect could say if the merge itself was
responsible for a failure.  That would not necessarily be clear in the
rebased case.  A useful guideline from Linus in these matters is that
if it doesn't have your signoff on it, you shouldn't rebase it.]

- After a bit of consideration, I favour having a new branch for each
new kernel version as Lars suggests.  That'd allow us a fresh start at
each version, to consider what made it upstream and how it affects our
patchset.  There would be rebases in order to create the new branch,
but all branches would remain "trackable" throughout their lifespans.

Each time we update to a new version, we would make our "downstream"
patchset slightly smaller to take into account the things which got
upstream, instead of sorting things out by creating a whole load of
conflicted merges. This comes at the price of losing the history in
the new branch as described above (rather, we create a new history
each time), but I think an occasional cleanup of a generally preserved
hsitory could be a good tradeoff.  Perhaps this cleanup should also
involve squashing all the commits on the driver branch down to create
an updated "master driver patch" with further work would add to.

- We could point "HEAD", or perhaps some other symbolic ref, at whatever
the most recent (vaguely stable!) branch is, to make things easy for
people wanting the latest stuff, since the branch names will change
every month or so.

- If we use a different Git porcelain (such as TopGit), I'd prefer to
choose a system which allows the history to be readable with the
"vanilla" porcelain - producing a history which makes sense when viewed
with (eg) gitk.  The old stgit-based system for andy-tracking, although
I'm sure it made a lot of sense to people using stgit, did not have
this property.  MERGE-what-where-now?

- From my research just now, it seems that TopGit does exactly what's
been described in this thread including periodic merges (rather than
rebases) with the upstream branch.  Obviously we don't necessarily need
to use that functionality if we don't want to.

- We will have a LOT of merges with this strategy.  TopGit hides them a
bit (I think), but they will be there.  Typically one merge per patch
or patch series if we keep the machine branches rigidly up to date.
However, our job is quite a large one and we may have to just accept
that some mess of this sort is inevitable.  It sounds like TopGit can
help us in this regard.

However, there is no fragility associated with the large number of
merges.  Git knows whether there is anything new to be merged, and
won't merge unnecessarily.  We could even automate the merging.  No-one
needs to look too deeply at the process which created the machine
branches.

- "Experimental" topic branches, such as the DRM stuff, could initially
be based on one of the machine branches.  That'd save having to create
a further "machine branch with experimental stuff" for testing.  I
think myself and the other DRM people are the only ones working in this
way, and as long as there aren't crazy amounts of rebasing involved, it
should be fine.

- Do we actually need separate trees for each machine?  It would reduce
the number of merges in each machine branch, but increase the overall
number of merges (common things have to be merged twice or more).

Tom

-- 
Thomas White <taw at bitwiz.org.uk>