From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756800AbcILJDM (ORCPT ); Mon, 12 Sep 2016 05:03:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:42200 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbcILJDL (ORCPT ); Mon, 12 Sep 2016 05:03:11 -0400 Subject: Re: linux-next: manual merge of the kbuild tree with Linus' tree To: Nicholas Piggin References: <20160912113224.792b24f0@canb.auug.org.au> <20160912125341.0596ed9f@roar.ozlabs.ibm.com> Cc: Stephen Rothwell , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , linux-arch@vger.kernel.org From: Michal Marek Message-ID: Date: Mon, 12 Sep 2016 11:03:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160912125341.0596ed9f@roar.ozlabs.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-09-12 04:53, Nicholas Piggin wrote: > Question, what is the best way to merge dependent patches? Considering > they will need a good amount of architecture testing, I think they will > have to go via arch trees. But it also does not make sense to merge these > kbuild changes upstream first, without having tested them. I think it makes sense to merge the kbuild changes via kbuild.git, even if they are unused and untested. Any follow-up fixes required to enable the first architecture can go through the respective architecture tree. Does that sound OK? Michal