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
