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