Kernel git reorganisation

[Daniel Drake]

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