All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	linux-arm-kernel@lists.infradead.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Vinod Koul <vinod.koul@intel.com>,
	Linus <torvalds@linux-foundation.org>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: linux-next: interesting merges in the arm-soc tree
Date: Wed, 04 Jan 2012 10:48:31 +0100	[thread overview]
Message-ID: <4F04206F.6070500@atmel.com> (raw)
In-Reply-To: <20120104104758.26b0ca5268d10fbf7b95903a@canb.auug.org.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/04/2012 12:47 AM, Stephen Rothwell :
> Hi all,
> 
> I noticed that the arm-soc tree has merged in the v4l-dvb and the 
> slave-dma trees today.   Is there some good reason for this?  It 
> fixes a few conflicts (but that is not excuse) and there may be 
> dependencies in a driver on the v4l-dvb tree (but maybe that means 
> that that driver should be merged via the v4l-dvb tree - it looks 
> like the "at91/drivers" is based on the v4l-dvb tree, so probably 
> doesn't depend on anything else on the arm-soc tree).
> 
> If nothing else, are you sure that neither of those merged trees 
> will rebase?  You have also just inherited any bugs in those two 
> trees.

We discussed this with Guennadi and Olof and decided to include this
dependency in arm-soc. Anrd and Olof said that the at91/drivers branch
could be merged late during the merge window and will make sure that
the corresponding v4l-dvb branch is actually upstream before sending
the pull request.

Here is the conversation about this:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/144547/focus=144743

Best regards,
- -- 
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPBCBqAAoJEAf03oE53VmQTtgH/2h9WBxjnwgcUrKOykHrXPPT
apB4y7FQA0EIaO6RWPi6LpXuBtEz+tV2mGyaXahUETgKQ9Oc459+FxoSoOmJyssh
vbaA4uWrPhdHXVVo464SLwxr/flUeb09iY3C+nIHn9JlYtqUriYOVUNCa+k/Oszp
AoaeDHPfjkkZ+07vZdjpYu9BC/NidijJvQDWCZ+Z4Jsfi7cygIB+HZGNAptPFmyq
jILk4LIdJcqsKmD0UA3i43WkTdqJQ4reZQk96POAX6151p7Ieh0PXNn68+oCYnwO
c6JAaM1FVsEhZAV1G/w0EpfDa0JNHep8h87GOHernrU6KuOVrWB0SCp5l0zERiw=
=mJTb
-----END PGP SIGNATURE-----

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: interesting merges in the arm-soc tree
Date: Wed, 04 Jan 2012 10:48:31 +0100	[thread overview]
Message-ID: <4F04206F.6070500@atmel.com> (raw)
In-Reply-To: <20120104104758.26b0ca5268d10fbf7b95903a@canb.auug.org.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/04/2012 12:47 AM, Stephen Rothwell :
> Hi all,
> 
> I noticed that the arm-soc tree has merged in the v4l-dvb and the 
> slave-dma trees today.   Is there some good reason for this?  It 
> fixes a few conflicts (but that is not excuse) and there may be 
> dependencies in a driver on the v4l-dvb tree (but maybe that means 
> that that driver should be merged via the v4l-dvb tree - it looks 
> like the "at91/drivers" is based on the v4l-dvb tree, so probably 
> doesn't depend on anything else on the arm-soc tree).
> 
> If nothing else, are you sure that neither of those merged trees 
> will rebase?  You have also just inherited any bugs in those two 
> trees.

We discussed this with Guennadi and Olof and decided to include this
dependency in arm-soc. Anrd and Olof said that the at91/drivers branch
could be merged late during the merge window and will make sure that
the corresponding v4l-dvb branch is actually upstream before sending
the pull request.

Here is the conversation about this:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/144547/focus=144743

Best regards,
- -- 
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPBCBqAAoJEAf03oE53VmQTtgH/2h9WBxjnwgcUrKOykHrXPPT
apB4y7FQA0EIaO6RWPi6LpXuBtEz+tV2mGyaXahUETgKQ9Oc459+FxoSoOmJyssh
vbaA4uWrPhdHXVVo464SLwxr/flUeb09iY3C+nIHn9JlYtqUriYOVUNCa+k/Oszp
AoaeDHPfjkkZ+07vZdjpYu9BC/NidijJvQDWCZ+Z4Jsfi7cygIB+HZGNAptPFmyq
jILk4LIdJcqsKmD0UA3i43WkTdqJQ4reZQk96POAX6151p7Ieh0PXNn68+oCYnwO
c6JAaM1FVsEhZAV1G/w0EpfDa0JNHep8h87GOHernrU6KuOVrWB0SCp5l0zERiw=
=mJTb
-----END PGP SIGNATURE-----

  parent reply	other threads:[~2012-01-04  9:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-03 23:47 linux-next: interesting merges in the arm-soc tree Stephen Rothwell
2012-01-03 23:47 ` Stephen Rothwell
2012-01-03 23:47 ` Stephen Rothwell
2012-01-04  0:58 ` Kukjin Kim
2012-01-04  0:58   ` Kukjin Kim
2012-01-04  9:50   ` Arnd Bergmann
2012-01-04  9:50     ` Arnd Bergmann
2012-01-04  9:48 ` Nicolas Ferre [this message]
2012-01-04  9:48   ` Nicolas Ferre

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=4F04206F.6070500@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=arnd@arndb.de \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=olof@lixom.net \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    --cc=vinod.koul@intel.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.