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

[Werner Almesberger]

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

> Also if we take the hit of arranging things for upstream
> per-incoming-patch, as the number of incoming patches increases the
> maintainer suffering level increases linearly.

Indeed :-(

> Whereas if we did it
> prior to a push upstream, assuming that we were able to form a
> methodology that would work, it would be much less sensitive to how many
> ingredients went into the pudding, meaning we can scale.

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.

So I'm concerned that, if we just let things slide, we'd end up with
a tree that would require too herculean an effort to ever get merged
into upstream quicker than local changes can happen.

Of course, this also means that we do have to start merging upstream
in earnest before I grow too tired and just give up :-)

Also, as a corollary, the current amount of crud (e.g., hairballs
like gta02-core.patch) will probably require an extended freeze to
sort out. Which places the right time to do all this right after we
release the MP kernel.

- Werner