[GIT PULL] omap changes for v2.6.39 merge window

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
> On Friday 18 March 2011, Russell King - ARM Linux wrote:
> > I do get the impression that you're extremely unhappy with the way ARM
> > stuff works, and I've no real idea how to solve that.  I think much of
> > it is down to perception rather than anything tangible.
> > 
> > Maybe the only solution is for ARM to fork the kernel, which is something
> > I really don't want to do - but from what I'm seeing its the only solution
> > which could come close to making you happy.
> 
> I'm still new to the ARM world, but I think one real problem is the way
> that all platforms have their own trees with a very flat hierarchy --
> a lot of people directly ask Linus to pull their trees, and the main
> way to sort out conflicts is linux-next. The number of platforms in the
> ARM arch is still increasing, so I assume that this only gets worse.

The reason that we've ended up with a flat heirarchy in terms of
developers is down to pressure.  There was a time when we had a more
structured system, where the sub-tree people submitted their patches
to me and the list, they'd be reviewed (mostly and mostly only) by me
before being merged into my tree and going upstream from there.

As the community grew, it got harder and harder to do decent reviewed
of those patches and so the acceptance rate dropped.

Eventually we switched to the current arrangement where I'm essentially
only concerned about core ARM code, and a few platforms which I have
personal interest in (or are contracted to look after.)

For the rest I just look at the patches, and send back what feedback I
can on them (which is mostly when my mailer turns a line red because
it's matched one of my mutt regexps for spotting common mistakes.)

> This would be no easier if everyone was asking you to pull their trees,
> as I believe was the case before that. The amount of code getting changed
> there is too large to get reviewed by a single person, and I believe
> neither of you really wants the burden to judge if all of the branches
> are ok (and complain to the authors when they are not).

Absolutely right - and the problem is that we still have no one who is
willing to step up and do the review.

What I was promised at the time was that by giving sub-tree maintainers
the loaded pistol, this problem of code quality would in effect be self-
correcting.  If they make a hash out of it, they'd have to be the ones
to fix it themselves.

Instead, what's happening is that the _entire_ ARM community, ARM
hardware manufacturers and so forth is being blamed here.

> Russell, do you think it would help to have an additional ARM platform
> tree that collects all the changes that impact only the platform code but
> not the core architecture? I believe that would be a way out, but requires
> a careful selection of people responsible for it. In particular, I don't
> think a single person can handle it without good sub-maintainers.

It's not that simple, as what happens when we have core ARM code updates
which ends up touching every single board file?  The result is conflicts
between trees, and that could get extremely messy indeed.

To be honest, given the politics, I don't want to be the one stuck in the
middle, receiving and endless stream of Linus' complaints about the way
the ARM community works, or the board support code.  However, inspite of
the sub-tree maintainers having the responsibility for their own code I
still find myself in the firing line.

And I have got to the point of just not giving a damn.  I can't change
the ARM community (I've tried over the years to get more active review
of platform changes and failed - and had it pointed out by folk like
Alan Cox, that such a system is impossible due to lack of motivation
by, eg, an OMAP person to review a Samsung change.)

If this ultimately means that Linus decides to throw ARM out of the
mainline kernel, then I guess we'll need a git tree setup somewhere to
track mainline, and to take the ARM merges, and do our own kernel
releases with different version numbering.  I'm quite prepared to do
that and run such a tree, and not give a damn about what the sub-arch
people do provided I can still make the necessary core ARM code changes
as required (and if some sub-arch breaks they get to fix it.)  However,
that would be entirely limited to just ARM arch stuff and not drivers.