linux-kernel - Re: [GIT PULL 4/5] ARM: arm-soc: late cleanups

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 7 May 2013 21:27:34 -0700
From:	Olof Johansson <olof@...om.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tony Lindgren <tony@...mide.com>, ARM SoC <arm@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [GIT PULL 4/5] ARM: arm-soc: late cleanups

On Tue, May 7, 2013 at 8:48 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:

> The ARM history has gotten much much better, but it's full of these
> kinds of incestuous merges. The pull requests I get are not truly
> independent development, although especially the early pull requests
> are much less tightly coupled than they used to be.

A lot of this comes from the way we structure the submaintainers
submissions to arm-soc: Cleanups on the bottom, then new SoC support,
then board and dt changes, etc. It means there are a lot of branches
that build on top of each other. It's not uncommon that a
submaintainer needs to build some new feature on top of both some
cleanup as well as some other new development, which is then what
causes some of these merges and backmerges.

While our splitting into categories (cleanup/soc/board/dt/drivers)
isn't 100% natural for each submaintainer, it does allow us to force
some thought into how it all fits together between vendors, and it
also allows us to split the code up into sets that make a bit more
sense (IMHO) when it's sent up to you.

Our lives (short-term) would be a lot easier if we just did one long
single branch and we sent that up, with mostly serial history. But I
also think it's been working reasonably well to expose a bit more
w.r.t. who's spending efforts on cleanup and refactoring old code
code, and who's pumping in new features and drivers.

I'm definitely open for suggestions on how to improve the way we do things.

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