Proposal for further openmoko kernel development

[Lars-Peter Clausen]

Hi Werner

Werner Almesberger wrote:
> Lars-Peter Clausen wrote:
>   
>> With the upcoming 2.6.31 kernel release basic support for the
>> freerunner as finally reached upstream.
>>     
> [...]
>   
>> What does this mean for the
>> community and distributions?
>>     
>
> Party !!! ;-)
>   
Yeay! :)
>> 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.
>>     
>
> Hmm, this sounds like a lot of trees with a lot of merging going
> on between them.
>   
Well, depends on your definition of 'a lot'. We would probably end up 
with ~10 driver trees + 3 machine trees + 1 all tree = ~ 15 trees.
Ok, compared to 1 tree, as we have now, but you have to consider that 
the more drivers get merged upstream the less trees we'll need.
And my proposed structure makes upstream inclusion a lot easier since 
you always have all changes to get a driver support in a single 
patchset. Instead of having to pick it from the huge series of patches 
which contain everything.

Merging will only take place in on direction. The all-tree merges gta01 
and gta02. The machine trees merge driver tree. But driver trees don't 
merge driver trees, as those should be independent to each other. And 
additionally half of the drivers are already pretty much done and won't 
see a lot of changes anymore.
Merging should usually take place after a driver has been rebased on a 
new upstream kernel or a new major feature has been implemented.

>> I also suggest to rebase our trees every major upstream release onto
>> the new upstream, to keep up with the latest changes in upstream and
>> again to keep the patchset maintainable.
>>     
>
> Do you mean "rebase" like in git-rebase ? If I understand things
> correctly, this makes it impossible to run a local tree off the
> tree that's being rebased. So the tree that's constantly being
> rebased would have to be a leaf.
>   
Yes, rebase as in git-rebase. At each major upstream release one would 
create a new branch from the current one and then rebase the new branch 
onto the new upstream kernel. Another possibility would be to merge 
upstream into the current branch. But I prefer to rebase, because it 
makes it a lot easier to keep a clean patch set.
>> this clearly defines who is responsible for what. With the current
>> model we have 3 or 4 people who have access to git, but there hasn't
>> been any agreement about what should be done by whom. Which as a
>> result has led to some confusion in the past, with none committing
>> potential patches.
>>     
>
> Wouldn't it be easier to solve that people problem than to create
> a complex structure that keeps them out of each other's hairs ?
>
> I prefer to have as few branches/trees/repositories as possible.
> It does make sense to have an "openmoko" branch to act as staging
> area for upstream submission, but I don't really see a need for
> having lots of branches below that.
>   
My proposal is not about keeping people out of each other's hairs. What 
it's about, is to keep patches from interfering with each other.  The 
peoples thing is just a side effect.
Cause what you get when you put everything into one big tree is second 
andy-tracking. Which is what I'm trying to avoid. I've gone through 
andy-tracking and rebased it onto .30 and .31 by hand and it was a real 
PITA. And I would rather not have to do this for each new kernel version 
again.

- Lars