On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > >> > 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. >> >> Yes it's a special case. I think the best way of handling such things is to get >> them in to Linus either right at the end of the merge window or the day after he >> releases -rc1. This is when most people's trees are mostly empty. > > Yes, that was the plan last time around as well - but the end of the merge window > is when we have the least maintainer bandwidth as well ... > > Anyway, I applied most of the patches (sans the rename), so the rename patch > should be a lot simpler to execute at the right moment this time around. Ingo, should we try this again some time? I have some ideas on how to make these sorts of changes easier to manage in the future, it involves having an automatic git rebase option to use Coccinelle for you if a patch is annotated to have been completely done with Coccinelle, but future tooling is needed for that [0]. In the meantime I (or you) can simply run the script at any point in time to catch all the names as-is in the kernel / point in time we decide to merge this simple rename. [0] http://kernelnewbies.org/KernelProjects/linux-oven 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
