Hi, We've recently talked about reorganising our kernel git repo, and avoiding having multiple repos like we have ended up with now. I propose the following (and I volunteer to do it):
When I say "archive X" I mean: create a tag named archive/X pointing at the current tip of branch "X", then delete the branch. And "archive X as Y" means: create a tag named archive/Y pointing at the current tip of branch "X", then delete the branch. - ask Chris to take a backup - olpc-2.6 is renamed to olpc-kernel - symlink set up so that olpc-2.6 still works - Existing master is tagged as archive/olpc-2.6.27 - master is reset to Linus HEAD as of now - remove "origin" branch (seems to be entirely contained within olpc-2.6.22) - archive stable as olpc-2.6.22 - archive testing as olpc-2.6.25 - archive xo-1.5 as xo15-2.6.30 - archive xo_1.5-2.6.30 as xo15-2.6.30-2 - archive xo-v2.6.30 as xo1-2.6.30 - archive 2.6.30-rc5 as olpc-2.6.30-rc5 - archive mfgtest - archive olpc-2.6.30 - remove olpc-2.6.31-updates (entirely contained within olpc-2.6.31) - archive olpc-2.6.34-dev - archive zones_of_death This leaves just 2 branches: olpc-2.6.31 and olpc-2.6.35 Then ARM can add "arm-3.0" where XO-1.75 11.3.0 kernels will be built from. When ARM does move into the repo (which should be soon, I'd hope), I'd like to request that it goes back to the "linear" usage of git that we've done for our other branches. I've been trying to keep an eye on the ARM kernel but it's simply too confusing with 2 repos, scratch branches, branches being rewinded/rebased, etc. Obviously theres a lot of churn going on, but that's the way it is, even post-production. A year from now it will be difficult to figure out what happened, unless you can go through the commit list. It is already painful doing that for XO-1.5 (look at the mess we made with the 2.6.30 branches above) but everything can still be traced quite easily. What would be nice to have is a branch where releases are built from, which doesn't ever get rewinded. Commits can be reverted, experimental stuff can be committed, but it shouldn't ever rewind or rebase. Things do get a bit messy, but every 2 months we should be looking at rebasing on top of a new Linus release (in a new branch), at which point commits can be merged and cleaned up, and we should be upstreaming heavily at the same time. Those measures will keep things manageable. Daniel _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
