Re: HTC Dream aka. t-mobile g1 support

[Alan Cox]

> For the most part, the answer is no.  People concentrate on their own
> areas, and won't look at someone with a new class of platforms (eg,
> the STMP or W90x900 stuff).

That would appear to be rational behaviour on their part.

> As I've already said, akpm tried to setup a mutual review between
> several ARM folk, but as far as I'm aware, it has so far been 
> unsuccessful (exactly why I don't know.)

Because its not rational economic behaviour on their part ?

> If patchwork just gathers up every patch which has ever been seen on
> a mailing list, then stuff will get lost at a higher rate than today
> and it will have a negative impact.

Stop trying to stand in the middle of the motorway and directing traffic.
You will get run over if you do that even if you are the best person on
the planet at that job.

The problem is perfectly sortable with a bit of experimenting. This is a
first suggestion - it might not work but it can't make things much worse
and if the current system doesn't work the first process to fix it is to
change things.

Make your tree the core ARM code only, any other patches you don't
accept. Aggressively push stuff out to platform code, and if people want
to change core code "because our platform is different" make them extract
it into the platform layer not carry it in the core bits.

Nominate a bunch of people for the main ARM platforms. What they put into
their platform specific trees goes direct from them to -next and if they
trash their own platform thats their problem (and they can come to you
for advice ;))

Leave it to the platform people to push their driver code through the
right channels.

You may be ten times better than them at the job, but there are a hundred
of them.

Each of the teams now has an economic focus that is in accord with what
they need to do "Get our platform working well", and as a secondary
effect if one of the teams accidentally messes up another they've both
got economic incentives to fix their shared problem. For core code
issues you can just follow Linus usual approach of "I'll merge this when
you've all stopped fighting and agreed a solution" (again you'll note
this creates the correct incentives).

Which all in all might give you a bit more time to go gliding rather than
running around like a lunatic trying to herd cats.

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