Proposal for further openmoko kernel development
stefan at openmoko.org
Wed Jul 29 08:55:01 CEST 2009
On Wed, 2009-07-29 at 01:49, Lars-Peter Clausen wrote:
> Werner Almesberger wrote:
> >Lars-Peter Clausen wrote:
> >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
May I ask you why you want to use complete trees for the split instead of
branches? What are you talking about here sounds a lot like topic branches to
me. A branch in your tree to work on a special feature/topic. You want a
patchstack like in quilt but using git features for it.
We tried stgit and guilt for exactly this setup at OpenEZX. Both failed due to
being useable for one person only, not a team. Then we found topgit and went
Topgit offers topic branches with interdependencies and the metadata available
for all team members in the git repo. Do a tg patch export in one topic branch
and you get all commits in this branch merged together in one nice clean patch.
Like quilt but this time with version control as well. :)
> 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.
Life is not that easy normally. How would you like to test your driver in the
special driver tree? Say it does not depend on another driver, which happens
more often then people like. You still need the machine file and maybe some
platform data. From your description this is in another tree which should never
be merged into the "low-level" driver tree.
> >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.
You really should avoid rebasing branches that are available public. It breaks a
lot for people that are trying to work with you in such a branch. Ask werner
about the problems he had with andy-trackinf being rebased all the time. (It
came from the fact that Andy did use stgit which worked well for him that way,
but not for others who did not have the stgit metadata). Rebasing should be a
BTW, topgit scales quite well:
More information about the openmoko-kernel