linux-kernel - Re: linux-next: manual merge of the tip 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:	Mon, 16 May 2011 11:47:06 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jacob Pan <jacob.jun.pan@...el.com>,
	Glauber Costa <glommer@...hat.com>,
	Dimitri Sivanich <sivanich@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Chris McDermott <lcm@...ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree

On Mon, 2011-05-16 at 12:37 +0100, Russell King - ARM Linux wrote:
> Obviously I shouldn't have added John's ack, which was sent during Monday
> nighttime to the commit so quickly, but instead waited a week before doing
> so.  Had I done that you wouldn't be complaining about "24 hours" or "18
> hours".

Yea, so its unfair for Russell to be taking all the heat on this one. 

I acked it, and I should have caught this issue. Part of the reason for
that is because my base for testing things is usually linus' tree, and
not tip.

Also the clocksource_register_hz/khz patches in tip (which also includes
Russell's "clocksource name const" patch) have been taking forever to
get upstream. They are low priority non-critical cleanups at this point,
so that's ok, but the original pull request for those was in Feb. And
the slower those sorts of things take to get upstream, the bigger the
window is for a collision.

So I'll try to be more proactive about grabbing and queuing such fixes
against the appropriate tip branch so that we can catch these issues,
and ideally the related patches properly move through their proper
maintainer tree.

At the same time, having recently done some similar consolidation work
in the RTC tree, as well as in the past the various clocksource work,
splitting up such changes across a number of different maintainers can
be a painfully slow process. This case isn't so bad because it was only
three spots, but I can understand if you don't see your patches pulled
into various maintainer trees quickly, you might use your normal
upstream route to get them in. Maybe it was a little too quick this
time, but I'm somewhat sympathetic to it.

thanks
-john

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