Message-ID: <a55d774e0906110412w7121d6d3t526ebd9c04d2d205@mail.gmail.com>
Date:	Thu, 11 Jun 2009 04:12:39 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Pavel Machek <pavel@....cz>, David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, ibm@...roid.com,
	san@...roid.com, rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 3:34 AM, Russell King - ARM
Linux<linux@....linux.org.uk> wrote:
>
> However, as a result of the complete lack of effort to update patches
> as a result of feedback coupled with my lack of bandwidth to review
> complex code implementing things like cross-bridge APIs (eg, ARM <->
> DSP communications channels), Brian basically gave up trying to get
> stuff into mainline.

Well, "gave up" feels a little final to me.  We still would like to
get stuff upstream.  I will admit to finding the process discouraging
at times, but a larger part of it is just finding the time to sit
down, tidy up the current state of our world against the tip-of-tree
on mainline, and push out another round of patches.  I'm hoping to
find some larger windows of time to devote to this later this year.

Since we also have to maintain a stable, shippable tree for products
going out the door and to provide baseline support for the platform,
we end up having to maintain multiple trees -- it's obviously not
realistic to expect that we're going to get 30000-50000 lines of new
code reviewed quickly, but we do need all the functionality there to
actually support shipping devices.  When time gets tight (more often
than I like), the towards-mainline stuff gets backburnered.
Obviously, we suffer for this in that we end up having more to rebase
every time we move forward, so it would be to our benefit to get
better at pushing this stuff upstream and reduce the delta between
mainline and our tree.

> Now, ask yourself this question: why should I have to be the one to
> review things like ARM <-> DSP communication channel code?  Hint: I
> don't want to because I know nothing about the subject.  Where should
> I send these people to get such code reviewed?  No idea, there seems
> to be no one _anywhere_ who would seem to be interested in it.

The drivers/staging system looks like it has some potential to help
here.  Greg has been scooping our generic code into there recently,
and I know Arve's seen patches for binder issues go by, etc.  It feels
(if I'm understanding the intent) a bit more like the model I'm more
used to (get a relatively clean piece of code that is functional
checked in, and then refine it).

> Andrew tried to resolve this review problem by getting some co-operation
> between various members of the ARM community - so that two or three
> people with large code bases would do mutual reviews and gain from
> each others efforts.  The result of that was... precisely nothing.  No
> interest in lifting a finger to help someone else.

I think Andrew's idea is a good one, but we just haven't had the time
to try to sort this out.  I'll have to see what we can do here.
Recently, we've been involved in omap3 work as well and have been
interacting more with folks in the omap kernel community as a result.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists