[PATCH 1/1 Try#2] clean-fiq.patch (was Re: [PATCH 0/3] FIQ)

Andy Green andy at openmoko.com
Fri Feb 1 20:17:06 CET 2008


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

Somebody in the thread at some point said:
> Andy Green wrote:
>> The structure doesn't persist in our output for upstream: unless I
>> misunderstood your whole point there about dismembering the patches.
> 
> That's true, but then upstream doesn't really need our internal
> structure. After all, they expect us to keep continuing to maintain
> our code ;-)

They would expect it, but they also expect to have oversight of what is
going on... as you say later gta02-core.patch isn't really that, its a
freaking bomb.  They really want a trickle of patches over time they can
digest without choking to death, not the "mochipatch"

http://en.wikipedia.org/wiki/Mochi

> Yes, but the question is whether we'd actually be able to do that.
> Just imagine trying to extract out per-feature patches from a "flat"
> tree. That would be an insane amount of extremely boring and
> error-prone manual work, even worse than the incremental splitting,
> since the splitting happens at least always at the surface.

Absolutely, but I am not thinking about the flat tree, it would be
insane.  I'm thinking about patch transformation out of git in the kind
of way patchutils enables -- sort of "patch domain arithmetic":

http://cyberelk.net/tim/software/patchutils/

if we effectively marked up the tree like stuff in /arch/arm/kernel is
one kind of patch, stuff in /arch/arm/mach-s3c2440 is another and so on
maybe there is a way through it all that gets you the mokopatch effect
synthesized without the work.

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

iD8DBQFHo3AyOjLpvpq7dMoRAjHrAJ0bbwtUAmn6P4AV/8ZYU4j9AgkRcACggucz
HKev8DVROBKHvqQmwMPkBZE=
=cZUi
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list