[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200716031842.GI1211629@lunn.ch>
Date: Thu, 16 Jul 2020 05:18:42 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jarod Wilson <jarod@...hat.com>
Cc: Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
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@...n.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.
Andrew
Powered by blists - more mailing lists