[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120723085413.38b5a314@endymion.delvare>
Date: Mon, 23 Jul 2012 08:54:13 +0200
From: Jean Delvare <khali@...ux-fr.org>
To: Zhang Rui <rui.zhang@...el.com>
Cc: Devendra Naga <develkernel412222@...il.com>,
Len Brown <len.brown@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org,
Fengguang Wu <wfg@...ux.intel.com>,
Durgadoss R <durgadoss.r@...el.com>
Subject: Re: [PATCH] thermal: fix build error at thermal_sys.c
Hi Rui,
On Mon, 23 Jul 2012 10:02:16 +0800, Zhang Rui wrote:
> BTW: what is the rule for linux-next?
> I refreshed the patches, did some test, and sent to mailing list
> saying that I want to push them to linux-next, please review.
> And then I got bug report from linux-next...
> shouldn't them be merged after I sending git pull request?
Your tree is set for linux-next inclusion. This means that, every day,
the current state of (one branch of) your tree makes it into that day's
linux-next. linux-next receives some testing so you may receive bug
reports that way (most frequently merge and build issues.)
But patches don't go from linux-next to Linus's upstream tree
automatically. Whenever you want your patches to actually go to Linus,
you must ask Linus explicitly to pull them.
So, when a build issue is found in linux-next, the right thing to do is
to blast the faulty branch and recreate it without the build breakage,
then have it go in at least one linux-next iterations to make sure you
did get things right this time, and only then ask Linus to pull from
your branch.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists