* Luis R. Rodriguez [off-list ref] wrote:

On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar [off-list ref] wrote:

quoted

* Andrew Morton [off-list ref] wrote:

quoted

quoted

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

So beyond the rename, can we also keep the old names as compatibility helpers, 
with a #define mapping them to the new names?

If so then please (re-)send the changes.

Thanks,

	Ingo