[Fwd: Re: new kernel ... / meaning of stable-tracking]

[Andy Green]

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

(wrote this yesterday in reply to Balaji but kernel list fell off the cc-s)

Somebody in the thread at some point said:

| Suppose I choose to submit the pcf50633 driver upstream. To do this, I
| would branch from stable-tracking and apply this patch there and offer it
| upstream. Also, I would frequently rebase the

Here's how to get the big diff:

git clone git://git.openmoko.org/git/kernel.git linux-2.6
git diff origin/master origin/stable-tracking >om-tracking.patch

om-tracking.patch is then a single 4.7MB patch file which represents the
total of all of our struggling on top of Linux HEAD.  If you look
through it you'll see everything we added (except ALSA stuffs that that
Graeme and Mark did a great job on pushing in upstream in realtime
already).  Despite we patched pcf50633 a bazillion times, like
everything else in om-tracking.patch it appears once as if we wrote it
in one sitting.

If we did it by sending upstream discrete patches for pcf50633, for
example, you would "carve out" the pcf50633 parts from om-tracking.patch
and glue them into a single smaller "om-pcf50633.patch" file only with
those parts.

If you take a look at that pcf50633 patch and you are holding your head
and groaning at the problems upstream will see, you need to patch your
branch for the issues first and repeat the diff and carving until it
looks good.


Then before sending it anywhere we need to

1) "stop upstream throwing chairs": confirm it applies and builds by
itself (we didn't miss any includes or whatever in this patch) on top of
a copy of master branch (pure upstream HEAD), and

2) "stop us shooting ourselves in the foot": confirm it still actually
works by pretending "it went upstream" and rebasing a copy of
stable-tracking on top of it, removing only those patches that try to
duplicate it, and physically testing the resulting build on a GTA02

I think 2) might be what you meant below by "process of rebasing it" -->

| proposed 'stable-tracking-tracking' branch with the stable-tracking
| branch. And, in the process of rebasing it with upstream, conflicts would
| be resolved then and there itself. And finally,
| this 'stable-tracking-tracking' branch would eventually go on to become
| our stable branch.

Hopefully this further explanation doesn't destroy the little feeling I
am getting that we might be understanding each other a bit.

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

iEYEARECAAYFAkjWBIQACgkQOjLpvpq7dMo6HQCfbSMkMuOO8SrAx/UIawXS0p8J
lJ8AoIbccXvWEZHN7RNRuY6blTZRpVKI
=5opo
-----END PGP SIGNATURE-----