Proposal for further openmoko kernel development
werner at openmoko.org
Wed Jul 29 00:24:01 CEST 2009
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 !!! ;-)
> Currently we have andy-tracking which is based on 2.6.29-rc3. And in
> my opinion andy-tracking is in a very bad shape,
> 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
Hmm, this sounds like a lot of trees with a lot of merging going
on between them.
> Ideally all trees would be initially based on the upstream kernel.
Sounds good. The closer we stay to upstream, the better.
> 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.
> 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.
Regarding access, I don't think there is a problem with handing out
commit access to git.openmoko.org liberally. I would not immediately
give commit access to someone whose work I don't know, but make them
first produce a few patches that are getting carefully reviewed.
Once we can see that the person "gets it", then we can give access.
We can always revert problematic changes and anything that goes to
upstream gets additional filtering anyway.
> What would have to be done to put this plan into action is to set up
> trees and provide access to those who need it. And to clarify who
> wants to take care of what.
I'm taking a sabbatical from the kernel until gta02-core has
progressed a bit further. After that, I hope I'll have more time
again to return to general kernel hacking.
More information about the openmoko-kernel