Re: [RFC] bonding driver terminology change proposal

From: Jarod Wilson <jarod@redhat.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
Date: Thu, 16 Jul 2020 01:43:18 -0400	[thread overview]
Message-ID: <CAKfmpSdSfrQjio2gSE7wSZnR82ROPwF4zH+Wyy4Xg-aOaOjvsQ@mail.gmail.com> (raw)
In-Reply-To: <20200716031842.GI1211629@lunn.ch>

On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote:
> > On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > Hi Jarod
> > >
> > > Do you have this change scripted? Could you apply the script to v5.4
> > > and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> > > many result in conflicts?
> > >
> > > Could you do the same with v4.19...v4.19.132, which has 20 fixes.
> > >
> > > This will give us an idea of the maintenance overhead such a change is
> > > going to cause, and how good git is at figuring out this sort of
> > > thing.
> >
> > Okay, I have some fugly bash scripts that use sed to do the majority
> > of the work here, save some manual bits done to add duplicate
> > interfaces w/new names and some aliases, and everything is compiling
> > and functions in a basic smoke test here.
> >
> > Summary on the 5.4 git cherry-pick conflict resolution after applying
> > changes: not that good. 7 of the 8 bonding fixes in the 5.4 stable
> > branch required fixing when straight cherry-picking. Dumping the
> > patches, running a sed script over them, and then git am'ing them
> > works pretty well though.
>
> Hi Jarad
>
> That is what i was expecting.
>
> I really think that before we consider changes like this, somebody
> needs to work on git tooling, so that it knows when mass renames have
> happened, and can do the same sort of renames when cherry-picking
> across the flag day. Without that, people trying to maintain stable
> kernels are going to be very unhappy.

I'm not familiar enough with git's internals to have a clue where to
begin for something like that, but I suspect you're right. Doing
blanket renames in stable branches sounds like a terrible idea, even
if it would circumvent the cherry-pick issues. I guess now is as good
a time as any to start poking around at git's internals...

-- 
Jarod Wilson
jarod@redhat.com