Hi Arend, Arend van Spriel <arend@xxxxxxxxxxxx> writes: >>> I really don't want to have you annoyed because the need of rebasing >>> your patch. What you said about Ralf's tree and linux-next isn't >>> exactly true. I do believe Kalle won't merge linux-next into >>> wireless-driver-next, so we have to wait for 4.2-rc1, then for Dave >>> merging Linus's tree, then Kalle merging Dave's tree. >> >> Well, it is an integration issue. So yes, wireless-drivers-next (and >> net-next) would not build for CONFIG_BCM47XX with the brcmfmac patch, >> because of the missing mips patch. However, the linux-next tree will >> have no build issue and consequently 4.2-rc1 will have no build issue. I >> think this is acceptable although I would like to hear the opinion of >> Kalle on this. > > Hi Kalle, > > Do you have an opinion on this? mips-next and linux-next now have the > function brcmfmac needs for CONFIG_BCM47XX so I could submit brcmfmac > patch, but that means wireless-drivers-next (and net-next) will not > build for CONFIG_BCM47XX until after the 4.2 merge window. The answer is clear: we must not ever break the build deliberately, in under any circumstances. Mistakes of course always happen but if we know a patch will break the build it should not be applied. So if patch A has a build dependency on patch B in another tree, we have to wait for that patch B to trickle down to wireless-drivers-next before I can commit patch A. There are other ways to speed this up if really needed but I don't see this case is important enough for the extra hurdle. I haven't followed all the details so I might be missing something but I think it would be good just to wait for 4.2-rc1, it's not that far anyway, and go with the original Arend's plan. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
