Kernel git reorganisation

[Paul Fox]

daniel wrote:
 > 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.

when you say "delete the branch", does this imply no longer being
able to look at the history leading to the X or Y tag?  i hope not.
if it's purely to give the tips more meaningful names, then that, of
course, is good.

 > 
 > - 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

fully agree here.

paul

 > 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
 > Devel at lists.laptop.org
 > http://lists.laptop.org/listinfo/devel

=---------------------
 paul fox, pgf at laptop.org