Proposal for further openmoko kernel development

[Paul Fertser]

Lars-Peter Clausen <lars at metafoo.de> writes:
> 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.

First of all, i want to say it one more time: great to see you on
board. :D

Second, i agree with most concerns Stefan raised. We don't seem to
need separate trees as branches are more flexible and manageable. And
for some specific tasks we have topgit looks like the proper tool.

Third, i think we'll want distro maintainers to use a branch that is
never rebased and easily bisectable.

I'm by no means a git expert so what i write should be taken as an
uneducated suggestion. Sorry if it doesn't make sense, skip to the
signature if you like ;)

We can have a branch for distro maintainers to where we will merge
upstream time to time. It will be creating merge commits so bisecting
will not work as good but it'll be still manageable. After initial
pulling of upstream here we rebase topic branches on the very same
commit and merge them. All subsequent fixes to the drivers in our
topic branches will have to be prepared separately: first as a fix to
the distributions tree, second it should be propely incorporated in
the corresponding topic branch (quite possibly rewriting history if
it'd make patch series more clean). Fixes to the drivers not in our
tree should be sent both to the distro tree and to upstream, but care
should be taken trying to avoid merge conflicts later. When a whole
driver comes back from upstream we might need to remove our
implementation first.

Could and should topic branches be rebased? Most probably yes, since
we want to submit them upstream. Will we lose some history this way?
Yes if you use git-rebase, no if we use topgit. We might also want to
have a branch for testing/development purposes where we don't care
about history, constantly resetting to the latest upstream and cleanly
pulling all the topic branches. That way we can ensure that once
support will come back from upstream it'll work.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com