Lars-Peter Clausen <[email protected]> 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:[email protected]
