linux-kernel - Re: HTC Dream aka. t-mobile g1 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Jun 2009 13:29:56 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Tony Lindgren <tony@...mide.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>, swetland@...gle.com,
	pavel@....cz, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, san@...roid.com,
	rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:

> On Thu, Jun 11, 2009 at 07:00:39AM -0700, Tony Lindgren wrote:
> > You suggested pulling each set as they get reviewed into some omap branch
> > in your tree, do you want to try that the next merge window?
> 
> If we're following Alan's suggestion, then as I see it you're entirely
> responsible for tracking what's in OMAP, getting it into linux-next and
> (I guess) ultimately sending Linus a pull request for it during the
> merge window.  I just become someone who can put their oar into reviewing
> OMAP patches as and when.

I don't see things exactly that way.

linux-next is a fully automated "let's dump everything together and see 
what is going to explode" kind of tree.  There is no patch review except 
from those who see their code being dammaged by the blast.  And it is 
automated in the sense that git pull operations are done automatically, 
even if someone deals with the merge conflicts manually afterwards.  My 
tree can be pulled into linux-next directly or through your tree, or 
even through both paths in parallel and git will deal with it just fine.  
And at the end of the day the linux-next tree is tossed in the garbage 
bin anyway.

I think that you, as the ARM maintainer, should continue gathering all 
the ARM subarchitectures into a coherent ARM tree and arbitrate 
conflicts when they occur.  You should especially keep a tight control 
on the very core ARM code.  But everything under arch/arm/mach-* you 
should let people maintaining those have control of that themselves and 
free yourself from that responsibility as much as possible.  The current 
directory structure is quite indicative of where the boundaries are 
already.  This way, if I make a mess of arch/arm/mach-orion5x/* then you 
just need to pass the blame straight to me.

Nicolas
--
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/