linux-kernel - Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock

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]

Date:	Tue, 13 Mar 2012 12:17:07 +0000
From:	Russell King <rmk@....linux.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [GIT PULL/NEXT] sched/arch: Introduce the
	finish_arch_post_lock_switch() scheduler callback

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> Look into the fine conflict report Russell: it conflicts with 
> *Linus's* tree, because it's based off some random 
> barely-beyond-rc1 development window -rc3 base. Even at the 
> commit date of Feb 27 we had a more stable base tree available - 
> and especially when you pulled it, several weeks down the line, 
> -rc3 was not a defensible base for the integrated result.

I'm not going to ask someone to rebase their patches after they've been
fully tested on a set of platforms.  It has been stated many times that
rebasing invalidates the testing that the patches have been subjected
to, and these have been tested by several different people on a range
of platforms.

It seems what _you_ care more about is having nice clean git trees and
proper git flow at the detriment to dealing with tested changes.

The fact of the matter is that I took a set of well tested patches into
my tree which _you_ were copied on multiple times, that Peter Z. was
aware of what was happening, and which trivially conflict with some other
change which happened along the way.  Such a trivial conflict does _NOT_
justify rebasing the patch set, thereby invalidating all the testing that
has done.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/