All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org, Olof Johansson <olof@lixom.net>,
	Tony Lindgren <tony@atomide.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: Re: OMAP and arm-soc's for-next branch
Date: Sat, 24 Mar 2012 18:14:42 +0000	[thread overview]
Message-ID: <201203241814.43002.arnd@arndb.de> (raw)
In-Reply-To: <20120324125029.GA29335@n2100.arm.linux.org.uk>

On Saturday 24 March 2012, Russell King - ARM Linux wrote:
> On Sat, Mar 24, 2012 at 12:22:56PM +0000, Russell King - ARM Linux wrote:
> > I've just re-merged the build tree for the nightly builds so it's now
> > based on v3.3, and pulled in the latest for-next from arm-soc.
> > 
> > I notice that the problem I reported earlier (see the "arm-soc + rmk's
> > tree boot failure on OMAP4430SDP" thread), which results in OMAP
> > being totally unable to boot, is still present.
> > 
> > As far as I'm concerned, as long as this remains unfixed in arm-soc,
> > arm-soc is not to push any branch containing the broken commit
> > (3ec2decb) upstream.
> 
> Just noticed that the fix for this has already been pushed into mainline.
> So, what this means is that anyone trying to bisect across this merge
> window with an OMAP platform will hit a range of commits which just won't
> boot.  That's really great stuff when the merge window contains the most
> probable set of commits for causing issues which would need to be bisected.

I had already pulled the omap_dss2 branch from Tomi into the next/cleanup
branch of arm-soc, in order to resolve a bunch of merge conflicts that we
discussed earlier.

This should limit the number of broken commits in the history to five,
and I could reduce that further to two commits if I rebuild the
next/cleanup branch in a different order, but I think it's not worth
it for that.

I definitely agree that the cleanup branches need a little more care.
The idea is really that large bug harmless changes go in there, also
to help simplify the bisection process. If stuff breaks in the cleanups,
I consider that worse than bugs that come in through new code.

	Arnd

  parent reply	other threads:[~2012-03-24 18:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24 12:22 OMAP and arm-soc's for-next branch Russell King - ARM Linux
2012-03-24 12:50 ` Russell King - ARM Linux
2012-03-24 17:28   ` Tony Lindgren
2012-03-24 18:14   ` Arnd Bergmann [this message]
2012-03-25  7:56     ` Russell King - ARM Linux
2012-03-25 10:19       ` Arnd Bergmann

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=201203241814.43002.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.