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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 19 Oct 2010 09:55:16 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	Nicolas Pitre <nico@...xnic.net>
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, 2010-10-18 at 22:47 -0400, Nicolas Pitre wrote:
> 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.

AFAIK before this thread, I should get CC'd when you modify me tree..
Maybe I'll setup some tools _now_ ..

> > 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.

Am I excited? Russell is the one getting excited .. I was the one trying
to correct the issues , so Linus doesn't have to deal with it.

Daniel


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