[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201105261213.46804.arnd@arndb.de>
Date: Thu, 26 May 2011 12:13:46 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@....linux.org.uk>,
Nicolas Pitre <nico@...xnic.net>,
Marc Zyngier <marc.zyngier@....com>,
Catalin Marinas <catalin.marinas@....com>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] ARM Subarchitecture group maintainership
On Thursday 26 May 2011, Mark Brown wrote:
>
> On Thu, May 26, 2011 at 10:33:55AM +0200, Thomas Gleixner wrote:
> > On Thu, 26 May 2011, Mark Brown wrote:
>
> > > I think the question is about the existing -next branches people already
> > > have - should they contain code that hasn't yet gone to you guys? We're
> > > doing that for audio at the minute (having subtrees in -next directly)
> > > and it's pretty helpful for miniising hassle for the maintainers of the
> > > core tree.
>
> > We obviously talk about arch/arm/[mach|plat]* stuff, drivers/ sound/
> > etc. should go through the relevant maintainer trees.
>
> Right, but the question is what to do with the subtrees that are in
> -next currently. I'm mentioning sound as an example of a tree with
> subtrees in -next directly.
I think all the subarch maintainers should basically stop having their
stuff included directly in linux-next, but instead have it pulled into
our tree, which has one aggregate -next branch that gets included there.
Arnd
--
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