linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Ingo Molnar <mingo@elte.hu>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jacob Pan <jacob.jun.pan@intel.com>,
	Glauber Costa <glommer@redhat.com>,
	Dimitri Sivanich <sivanich@sgi.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Chris McDermott <lcm@us.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree
Date: Mon, 16 May 2011 11:47:06 -0700	[thread overview]
Message-ID: <1305571626.2915.24.camel@work-vm> (raw)
In-Reply-To: <20110516113707.GQ30539@n2100.arm.linux.org.uk>

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

  reply	other threads:[~2011-05-16 18:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-13  3:14 linux-next: manual merge of the tip tree with the arm tree Stephen Rothwell
2011-05-13  8:06 ` Ingo Molnar
2011-05-13  8:37   ` Russell King - ARM Linux
2011-05-13  8:47     ` Thomas Gleixner
2011-05-13  9:26     ` Ingo Molnar
2011-05-13 10:04       ` Thomas Gleixner
2011-05-13 17:25       ` Russell King - ARM Linux
2011-05-16  7:21         ` Ingo Molnar
2011-05-13 21:36       ` Russell King - ARM Linux
2011-05-16  7:31         ` Ingo Molnar
2011-05-16  7:42           ` Russell King - ARM Linux
2011-05-16  9:17             ` Ingo Molnar
2011-05-16  9:19               ` Russell King - ARM Linux
2011-05-16  9:40                 ` Ingo Molnar
2011-05-16 10:07                   ` Russell King - ARM Linux
2011-05-16 11:06                     ` Ingo Molnar
2011-05-16 11:37                       ` Russell King - ARM Linux
2011-05-16 18:47                         ` John Stultz [this message]
2011-05-17 11:56                         ` Ingo Molnar
2011-05-17 18:28                           ` Russell King - ARM Linux
  -- strict thread matches above, loose matches on Subject: below --
2013-06-20  5:05 Stephen Rothwell
2020-05-29  5:29 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1305571626.2915.24.camel@work-vm \
    --to=john.stultz@linaro.org \
    --cc=glommer@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jeremy@xensource.com \
    --cc=konrad.wilk@oracle.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sfr@canb.auug.org.au \
    --cc=sivanich@sgi.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).