Re: thermal patches in linux-next

Hi, Stephen,

On 五, 2012-08-10 at 09:08 +1000, Stephen Rothwell wrote:

Hi Rui,

On Thu, 09 Aug 2012 14:45:46 +0800 Zhang Rui [off-list ref] wrote:

quoted

On 二, 2012-08-07 at 10:53 +0800, Zhang Rui wrote:

quoted

Hi, all,

I just created a git tree for catching all thermal changes.
http://git.kernel.org/?p=linux/kernel/git/rzhang/linux.git;a=summary
and I also created the next branch, which I'd like to be set for
linux-next inclusion, but don't know how.

I create a tree for thermal management,
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git

could you please include my next branch for linux-next?

Included from today.

Thank you.

quoted

And could you please drop these commits
ef25a0fe0087963c1611c1c8903886fbea053f76
09ec52fca274ba88d68df3198de92abdaaff417b
ab6d2f029358c917508bf88bbd6a9193a8e39fc8
66447fa993cbce56b4076f169a56f62350f6c7b8
ec62abb8b46021ca9ee6b8692b26974ace9007f0
5ecbaf57d7885eedd924e391d91847d3df9fe0f8
851414b2249afd8c128d29912dfd7060eaea8932
and pull my next branch instead?

That is not how linux-next normally works.  Those commits are in Adnrew's
quilt series, so you need to ask him to drop them.  However, because of
the way the akpm tree works, any duplicate patches will disappear from my
copy of Andrew's series.

Andrew,

could you please drop these patches?
these commits either will be or has been re-based on top of my tree.

thanks,
rui

In this case, I will remove them if they conflict too much or you take
them (rebased) into your tree.

Andrew, any chance of a new mmotm series?  I am still working off (a reduced
part) of the mmotm series from July 21 ...

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.