public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Len Brown <len.brown@intel.com>,
	Stephen Warren <swarren@nvidia.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: next-200110804 ARM build break (cpuidle_call_idle)
Date: Fri, 5 Aug 2011 10:21:13 +0200	[thread overview]
Message-ID: <20110805082113.GA32299@elte.hu> (raw)
In-Reply-To: <CA+55aFz1szgUHVLUS=gBM-+FO_PfLYPCDWFNZWZeu8M_M-cbiw@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [...] In fact, I'm seriously considering a rather draconian measure 
> for next merge window: I'll fetch the -next tree when I open the 
> merge window, and if I get anything but trivial fixes that don't 
> show up in that "next tree at the point of merge window open", I'll 
> just ignore that pull request. Because clearly people are just not 
> being careful enough.

That would be really nice - in hindsight, had you done that in this 
cycle it would have solved about 80% of the merge window bugs i ran 
into!

I have trouble getting my own fixes out on time because -git is so 
untestable at the moment and i need to test on -git now that our new 
bits are upstream.

 [ In fact i'd even argue that the snapshot should be a couple of 
   days _before_ the merge window opening. The trivial annoyances and
   serious showstoppers need a couple of days of latency to get 
   discovered in linux-next and there's always a late rush of getting 
   stuff into linux-next just before the final release. linux-next
   also has weekend latency which can add up to 3 days to the 
   normally 2-3 days latency of discovering showstoppers. ]

People can still try to tempt you with late stuff, with an [RFC GIT 
PULL] tag, clearly and visibly declaring that it's a workflow 
exception and that it's fully discretional on your side with no 
maintenance problems if it's skipped to the next merge window.

Thanks,

	Ingo

  reply	other threads:[~2011-08-05  8:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 20:35 next-200110804 ARM build break (cpuidle_call_idle) Stephen Warren
2011-08-04 23:04 ` Stephen Rothwell
2011-08-04 23:29 ` Stephen Rothwell
2011-08-05  0:52   ` Stephen Rothwell
2011-08-05  2:42     ` Linus Torvalds
2011-08-05  8:21       ` Ingo Molnar [this message]
2011-08-05 19:44       ` Brown, Len

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=20110805082113.GA32299@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=swarren@nvidia.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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