On Tue, Aug 25, 2015 at 01:43:58PM -0700, Andrew Morton wrote: > On Tue, 25 Aug 2015 17:48:37 +0200 "Luis R. Rodriguez" <mcgrof@xxxxxxxx> wrote: > > > On Tue, Aug 25, 2015 at 09:53:18AM +0200, Ingo Molnar wrote: > > > Which kernel is this against? It has conflicts in 3 files with Linus's latest: > > > v4.2-rc8. > > > > Sorry I based it on linux-next, will respin the rename patch onto tip/auto-latest > > > > Doing that will make the patch kinda useless, because then the patch > will trash more mature work which is pending in linux-next, one week > before the merge window opens. > > A better plan would be to base the patches on linux-next then wait for > 4.3-rc1. There's a catch-22 issue here either way, for instance this rename patch has been being baked for probably 2 releases already but the difficulty has been trying to find the appropriate time to merge it without conflict. If you do it in the beginning of the merge window, you have to ask yourself in what tree it will be done. Since subsystems are topic specific that means that subsystem will end up having a conflict at the end of the merge window. If you do it at the end you run into the issue you describe. So unless I'm missing something, perhaps metrics to argue one way is better than another, it seems today this is up up to a subsystem's maintainer's preference? There are more subtle issues with this though, I've identified similar problems before and proposed one solution to it could be a linux-oven [0], in that thread I describe other issues and why I think a linux-oven might help. Perhaps the biggest change that comes to mind that could have caused tons of collateral was the UAPI change David Howells did years ago, when did that go in, at the end of early? In retrospect what would have helped? Anyway, both version of the patch are now available, up to you guys :) [0] http://lkml.kernel.org/r/20150619231255.GC7487@xxxxxxxxxxxxxxxxxxxxxxxxx Luis -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
