But please bear with me here, what if we queue this patch up to -stable ?
You've got to be seriously kidding me that your idea is to submit an
incredibly diruptive driver rename to -stable to solve this problem.
That is completely a non-starter.
The whole idea is to _MINIMIZE_ the amount of change happening in
-stable in order to avoid regressions and negative consequence for
everyone using the -stable tree.
I am strongly against a major reorganization of this driver, sorry.
The Synopsys folks want to do the same thing for the stmmac driver,
for even more nefarious reasons, and I'm rejecting all of their
attempts to do that as well.
If you look in that thread, they said they would "help" with the
-stable backports, and in there I explained why that is a completely
empty gesture. There are people doing the backports outside of your
spehere of influence, who need to get their work done "right now" and
aren't going to consult you and be on your schedule for doing those
backports.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
But please bear with me here, what if we queue this patch up to -stable ?
You've got to be seriously kidding me that your idea is to submit an
incredibly diruptive driver rename to -stable to solve this problem.
That is completely a non-starter.
The whole idea is to _MINIMIZE_ the amount of change happening in
-stable in order to avoid regressions and negative consequence for
everyone using the -stable tree.
I am strongly against a major reorganization of this driver, sorry.
The Synopsys folks want to do the same thing for the stmmac driver,
for even more nefarious reasons, and I'm rejecting all of their
attempts to do that as well.
If you look in that thread, they said they would "help" with the
-stable backports, and in there I explained why that is a completely
empty gesture. There are people doing the backports outside of your
spehere of influence, who need to get their work done "right now" and
aren't going to consult you and be on your schedule for doing those
backports.
David,
In principle I agree, but as I previously wrote backporting this
driver is already a bear. We need to do something here as this is
quickly approaching being infeasible to backport. Even if we don't
restructure the directories I'd still like to see some effort towards
feature modularization and isolation.
Tom
From: David Miller <davem@davemloft.net> Date: 2017-01-19 05:38:36
From: Tom Herbert <redacted>
Date: Wed, 18 Jan 2017 21:22:53 -0800
In principle I agree, but as I previously wrote backporting this
driver is already a bear. We need to do something here as this is
quickly approaching being infeasible to backport. Even if we don't
restructure the directories I'd still like to see some effort towards
feature modularization and isolation.
There simply is a lot changing all the time, no restructuring is going
to reduce that. The driver simply gets a lot of churn.
Backporting such things through a bunch of file and/or directory
renames is seriously nothing but asking for more punishment.
That's why I am against it.
On Thu, 2017-01-19 at 00:38 -0500, David Miller wrote:
From: Tom Herbert <redacted>
Date: Wed, 18 Jan 2017 21:22:53 -0800
quoted
In principle I agree, but as I previously wrote backporting this
driver is already a bear. We need to do something here as this is
quickly approaching being infeasible to backport. Even if we don't
restructure the directories I'd still like to see some effort
towards
quoted
feature modularization and isolation.
There simply is a lot changing all the time, no restructuring is
going
to reduce that. The driver simply gets a lot of churn.
Backporting such things through a bunch of file and/or directory
renames is seriously nothing but asking for more punishment.
That's why I am against it.
So, I spent the better part of two years dealing with this after the
drivers/net/mellanox drivers/net/ethernet/mellanox rename, so I'll
chime in. Especially since Tom's problem directly relates to the
issues I dealt with when trying to take the latest Mellanox driver and
shoe-horn it into a Red Hat kernel that didn't have the same net core
(I had to pick and choose which mlx patches to take in order to work
with our existing net core, and the files were renamed on top of that).
If you rename a file from place A to place B and keep the file the
same, then a git backport can be done using techniques such as git
cherry-pick with the --follow option enabled. It's slow, but works.
But that's not what you've brought up. You brought up continuing the
rename to go further and split code out into files based upon features.
While git cherry-pick can follow renames mostly automatically, it can
not follow refactors. If they move the tcflower stuff out to a file on
its own, and you then attempt to backport some fix that touches the
tcflower support in the new location while you have not taken the move
patch, you will find that git will be totally stymied.
What you have now is not perfect and you have to sort through commits
to get the right ones and skip the ones you can't support, but things
mostly apply except when context diffs break issues. With the refactor
and separation you speak of, git will be totally unable to help and you
will have to manually edit patches to point at new files or hand edit
the files to apply the patches.
I understand the desire for order instead of chaos, but it really will
not help. Bringing patches from the new order back to the old chaos
will be so much harder than just continuing as things are that you will
silently curse the change shortly after it is made.
--
Doug Ledford [off-list ref]
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD