linux-kernel - Re: 2.6.19 -mm merge plans

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]

Message-ID: <20060924074837.GB13487@xi.wantstofly.org>
Date:	Sun, 24 Sep 2006 09:48:37 +0200
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Dave Jones <davej@...hat.com>, David Miller <davem@...emloft.net>,
	jeff@...zik.org, davidsen@....com, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans

On Fri, Sep 22, 2006 at 09:21:32AM -0700, Linus Torvalds wrote:

> > Hmm. Some trees do seem to get pulled more often than others.
> > Linus, is there a upper limit on the number of times you want
> > to see pull requests? It strikes me as odd, so I'm wondering
> > if there are some crossed wires here.
> 
> I personally prefer to not see _too_ many pull requests, since that
> to me indicates that people don't take advantage of the distributed
> nature of git, and don't let things "simmer" in their own tree for
> a while.

ARM has many sub-architectures, and patches for each of the sub-archs
typically (not always) come from the same person in ARM land, which
typically means that the total set of ARM changes doesn't really need
much integration testing as a whole.

Changes that span sub-architectures (such as genirq) are usually
discussed on the mailing list first, and tested before they get
committed to any tree.  I.e. on the few occasions that we do need
to test ARM-wide changes, we just email patches around rather than
asking folks "whether 2.6.30-rmk42 works."

Due to this, by the time a patch gets sent to rmk it's Obviously
Perfect, and the remaining testing work is 99% integration testing
with concurrent changes to other subsystems -- mtd, netdev, usb, etc.

In fact, I'd argue that there are more patches that span arch/arm plus
some other part of the tree (inter-related mtd bits, netdev bits, usb
bits, framebuffer bits), than there are patches that span different ARM
sub-architectures.

For example, a driver for the ethernet MAC in the ARM cpu that I have
here was recently applied by jgarzik, but I cannot submit the arch/arm
hooks to make use of this driver until jgarzik's tree is merged upstream
_and_ rmk rebases the half a megabyte of pending ARM changes on this
tree.  If I submit the hooks to rmk when the driver goes upstream, rmk's
private tree (probably still based on 2.6.18 when that happens, so won't
have the relevant netdev changes) will break.

To make making these kinds of changes easier without sending stuff
upstream so regularly, rmk would have to either pull from upstream
regularly or rebase his tree on upstream regularly, both of which
don't seem like desirable options.

Also, I do want to track upstream git, as every now and then changes
are made upstream that break ARM, and we want to be able to detect that
quickly.

Due to the nature of ARM work, rmk maintaining a long-lived tree for
stuff to 'simmer in' would probably reduce the burden on Linus but
would not have much of an advantage otherwise, IMHO.

cheers,
Lennert
-
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/