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

Andy Green andy at
Fri Sep 19 15:13:26 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| I've started to work a bit on that program that can generate topic
| patches directly from our repository, but I realized later that I
| tried to be too clever about how this tracked changes and that my
| algorithm wouldn't work. (I tried to make it track the history of
| every single line, but there are too many ambiguities to handle.)
| So I'll have to do this again. It's been mainly a pencil and paper
| exercise so far anyway.

First of all good luck to Balaji working on that lot :-)

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

For some months I have been maintaining the *-tracking branches in git,
which are our stuff ported on to whatever is current at the time.  The
last update is from yesterday, currently FIQ is broken but most other
stuff seemed to work OK.  It seems Balaji should be looking at
stable-tracking branch in git, not stable.  I last updated it yesterday.

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.

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.  This isn't as pretty as some
magic tool, but once we got a chunk upstream, we can directly feed
upstream the relevant patches without any further processing under
normal conditions.

Anyway those're my suggestions to Balaji - use stable-tracking as your
basis, and chop the diff up by hand -- something easy first I would think.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list