Hi Michal, [For the new cc's, we are discussing the "thin archives" and "link dead code/data elimination" patches in the kbuild tree.] On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek <mmarek@xxxxxxx> wrote: > > > > 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? > > And if you guarantee not to rebase the kbuild tree (or at least the > subset containing these patches), then each of the architecture trees > can just merge your tree (or a tag?) and then implement any necessary > arch dependent changes. I fixes are necessary, they can also be merged > into the architecture trees. Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL patches that produce warnings on PowerPC :-( (And I am still reverting the PowerPC specific one of those patches). -- Cheers, Stephen Rothwell -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
