linux-kernel - Re: linux-next: current pending merge fix patches

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: <20100301081021.GB8049@elte.hu>
Date:	Mon, 1 Mar 2010 09:10:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Linus <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	Len Brown <lenb@...nel.org>, Dave Jones <davej@...hat.com>,
	Jean Delvare <khali@...ux-fr.org>, Greg KH <greg@...ah.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Sage Weil <sage@...dream.net>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Al Viro <viro@...IV.linux.org.uk>,
	"\"J??rn Engel\"" <joern@...fs.org>
Subject: Re: linux-next: current pending merge fix patches

* Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> This could also be taken as a reminder to the respective maintiners that 
> they may want to do a merge of your tree before asking you to pull theirs.

I dont think that's generally correct for trivial conflicts: it's better if 
Linus does the merge of a tree that is based in some stable tree.

It causes slightly messier criss-cross history: there will be the back-merge 
commit plus the inevitable merge commit from Linus. It also makes bisection a 
bit messier:

For example when bisecting i generally consider the 'boundary' of where Linus 
pulls as a 'known point of stability': i.e. the 'subsystem side' is expected 
to be well-tested and if there's a problem on that side, it's that subsystem's 
domain.

"Linus's side", during the merge window, is a rolling tree of many freshly 
merged trees, which inevitably piles up a few problems.

So it's IMO somewhat better to keep that boundary and not push out Linus's 
side into subsystem trees: which then may merge a few new patches after having 
merged Linus's tree, intermixing it all into a non-bisectable combination.

Plus there's also an indirect effect: it keeps people from merging back 
Linus's tree all the time.

So i'd argue to not backmerge during the merge window (and i have stopped 
doing that myself a few cycles ago, and it clearly helped things) - but in any 
case it's certainly no big deal and up to Linus i guess.

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