new kernel ... / another try at getting anything upstream

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Something I didn't see you mention is that upstream is interested in
|> living patches against their HEAD, not what we ship (2.6.24).
|
| Yes, good point. Seems that we're close to being able to move forward
| with our stable branch as well. That would be a good thing to do in
| general, since there's already a number of bugs that have been fixed
| in upstream but that still exist in our tree.
|
| How would you feel about switching to *-tracking once Om2008.9 is out ?

We shouldn't move to the tracking branch since it just follows upstream
HEAD all the time, that's what it is for to create patches that allow us
to follow along.

Soon we need to jump to 2.6.26, which I also have had ready for some
time in git, unless we tie it to Holger's hw ECC NAND patches that are
incompatible with NOR U-Boot we can do it when we are ready rather than
sync it to one of the userspaces.  Before then the device tree
reordering stuff currently stalled on Glamo bugs needs to get fixed I
think, it's a great opportunity to move forward on suspend-resume at the
same time.  So I intend to sort that and then propose we shift to 2.6.26.

|> Carsten had an interesting way to come at a general attack on upstream
|> that I think you should reconsider since you didn't get anywhere with
|> your automated method the last six months.
|
| Well, I didn't actually have more than about a week to spend on
| actually trying to make this thing work, so it's not quite *that*
| bad :-)

It has been six months...

|> His concept was to blow through our git history by essentially diffing
|> upstream and our patched tree in a single flat diff, then carving it up
|> by hand into chunks to be fed upstream.
|
| That's the traditional way, yes. I have used that approach many times
| in the past and I would do it again if we could just freeze other
| development on our tree while everybody is working on pushing things
| upstream. But I don't think this is a realistic model.

I don't see we need to freeze development.  You can pick a day to take
our tree and do the diff, and aim to get that upstream.

Anything you got upstream based on "the reference day", say it was
pcf50633 from a week ago :-), the patches on stable-tracking since the
reference day that are relevant can just be sent upstream as well.

Anyway as I said six months ago, the main thing is that this belated
upstream effort should not trash up current development.  Take a
snapshot of the stable-tracking tree one day and see what you can get
upstream.  We can deal with it when we see the upstream stuff coming in
from upstream, otherwise it should not affect stable branches except
stable-tracking here at all.  We don't ship the new upstream until we
decide to make a general uplevel like this proposed 2.6.26 one.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjTuG4ACgkQOjLpvpq7dMqbegCgiELur09Aw58oQNAB+y2qTJAu
fmoAn1R3YJBfBggu1F/gzue2taKNZsS+
=EKtM
-----END PGP SIGNATURE-----