linux-kernel - Re: linux-next: manual merge of the msm tree with the arm tree

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] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.1010182227440.2764@xanadu.home>
Date:	Mon, 18 Oct 2010 22:47:17 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Russell King <rmk@....linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Jeff Ohlstein <johlstei@...eaurora.org>
Subject: Re: linux-next: manual merge of the msm tree with the arm tree

On Mon, 18 Oct 2010, Daniel Walker wrote:

> I can say that I know for a fact that people don't read every patch, or
> every email, or keep track of every single thread. I don't think it's
> reasonable to expect people to do that. there's too many email, too many
> threads, too many discussions etc ..

I'm not saying that you should keep track of every threads.  But you 
should at least pay attention to what thread is being discussed, simply 
by looking at the subject line.  Any good MUA will let you sort emails 
and collapse them into thread view.  And scoring those incoming emails 
with "arch/arm/mach-msm" for example is a quick way for you to be 
noticed when a patch might be changing something in your area.  Tools 
are there for you.

> This discussion isn't really about that. It's not about people reading
> every single patch, which we know they don't do. This is about conflicts
> in -next.

Glad to get back to the original issue.

> These patches caused conflicts in -next .. What more could I have done
> to prevent conflicts coming from another tree and patches that appear
> not to effect me? Even if I read all the patches, and threads, it still
> seems unreasonable to expect maintainers to predict conflicts not coming
> from their own tree's.

In this particular case, Stephen did fix the trivial merge conflict.  
Most probably Linus could have done the same.  There is nothing you 
needed to do in that case.  Or you could have waited until RMK's tree 
hits mainline, then you merge that, fixing the issue within that merge, 
before asking Linus to pull.

And if the merge in linux-next turned out not to be that trivial, or you 
have new machine entries in your tree that failed to compile due to the 
missing fixup, well that's fine too because that's _exactly_ what the 
purpose of the linux-next tree is: finding issues like this before the 
real merge in Linus' tree.  So in this case the system did work: the 
conflict was identified by the tool and you were notified.

And the simplest solution to this is simply to merge your stuff into 
RMK's tree in this case, so the generic change affecting all ARM 
machines will cover yours as well.  Incidentally that's what has been 
asked of you.

See?  Nothing to really get excited about.

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/