Re: Kernel git reorganisation

[Chris Ball]

Hi,

On Thu, Aug 04 2011, Daniel Drake wrote:
>> 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):
>
> This has now been done.

I've pushed olpc-3.0:arm-3.0 to olpc-kernel:arm-3.0 now, so Martin can
start using olpc-kernel:arm-3.0 as the branch to include in ARM builds.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Kernel git reorganisation

[Daniel Drake]

On Wed, Aug 3, 2011 at 9:36 PM, Daniel Drake  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):

This has now been done.

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Kernel git reorganisation

[Paul Fox]

daniel wrote:
 > On Thu, Aug 4, 2011 at 3:08 AM, Paul Fox  wrote:
 > > 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?
 > 
 > No, "git log archive/olpc-2.6.30" will still show full history, and
 > "git checkout -b olpc-2.6.30 archive/olpc-2.6.30" will locally
 > recreate the branch as before.
 > 
 > The only real difference is that you can't commit to branches that
 > have been archived in this manner, unless you recreate the tag
 > pointing at a new tip.

thanks.  i figured/was hoping it was something like this.

go for it.

paul
=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Kernel git reorganisation

[Daniel Drake]

On Thu, Aug 4, 2011 at 3:08 AM, Paul Fox  wrote:
> 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?

No, "git log archive/olpc-2.6.30" will still show full history, and
"git checkout -b olpc-2.6.30 archive/olpc-2.6.30" will locally
recreate the branch as before.

The only real difference is that you can't commit to branches that
have been archived in this manner, unless you recreate the tag
pointing at a new tip.

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Kernel git reorganisation

[Chris Ball]

Hi Dan,

On Wed, Aug 03 2011, Daniel Drake wrote:
> 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):

+1.  Go ahead!

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel