[ovs-dev] [PATCH v2 2/2] travis: Make it possible to build against a dpdk branch.

[Ilya Maximets]

On 20.06.2019 14:56, Stokes, Ian wrote:
>>> -----Original Message-----
>>> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
>>> bounces at openvswitch.org] On Behalf Of Stokes, Ian
>>> Sent: Thursday, June 20, 2019 11:53 AM
>>> To: Ilya Maximets <i.maximets at samsung.com>; David Marchand
>>> <david.marchand at redhat.com>
>>> Cc: ovs dev <dev at openvswitch.org>
>>> Subject: Re: [ovs-dev] [PATCH v2 2/2] travis: Make it possible to build
>>> against a dpdk branch.
>>>
>>>> On 19.06.2019 14:35, David Marchand wrote:
>>>>>
>>>>>
>>>>> On Wed, Jun 19, 2019 at 1:22 PM Ilya Maximets
>> <i.maximets at samsung.com
>>>> <mailto:i.maximets at samsung.com>> wrote:
>>>>>
>>>>>     On 19.06.2019 10:26, David Marchand wrote:
>>>>>     > Rework the build script so that we can pass branches and tags.
>>>>>     >
>>>>>     > With this, DPDK_VER can be passed as:
>>>>>     > - a string starting with refs/ which is understood as a git
>>>> reference.
>>>>>     >   This triggers a git clone on DPDK_GIT (default value points
>> to
>>>>>     >   https://dpdk.org/git/dpdk) for a single branch pointing to
>>> this
>>>>>     >   reference (to save some disk),
>>>>>     > - else, any other string which is understood as an official
>>>> release.
>>>>>     >   This triggers a tarball download on dpdk.org
>>> <http://dpdk.org>.
>>>>>     >
>>>>>     > Signed-off-by: David Marchand <david.marchand at redhat.com
>>>> <mailto:david.marchand at redhat.com>>
>>>>>     > ---
>>>>>     > Changelog since v1:
>>>>>     > - removed (now unneeded) directory renames
>>>>>     > - added a "git log" so that we have the current git revision
>> in
>>>> the logs
>>>>>     >
>>>>>     > ---
>>>>>
>>>>>
>>>>>     Thanks!
>>>>>
>>>>>     I tested this patch with:
>>>>>
>>>>>     - DPDK=1 DPDK_GIT="https://dpdk.org/git/dpdk-stable"
>>>> DPDK_VER="refs/heads/18.11"
>>>>>
>>>>>     and
>>>>>
>>>>>     - DPDK=1 DPDK_VER="refs/heads/master"
>>>>>
>>>>>     Works fine.
>>>>>
>>>>>
>>>>> Thanks Ilya.
>>>>>
>>>>> I could have detailed my non-reg tests:
>>>>> - DPDK=1
>>>>> - DPDK=1 DPDK_VER=18.11.2
>>>>> - DPDK=1 DPDK_VER=refs/tags/v18.11.2
>>> DPDK_GIT=http://dpdk.org/git/dpdk-
>>>> stable
>>>>> - DPDK=1 DPDK_VER=refs/heads/18.11
>> DPDK_GIT=http://dpdk.org/git/dpdk-
>>>> stable
>>>>>
>>>>>
>>>>>
>>>>>     So, I pushed this and the previous patch to master.
>>>>>
>>>>>
>>>>> Cool, so I suppose you will handle the changes on dpdk-latest,
>> right?
>>>>
>>>> Not sure. Ian managed these branches (hwol, latest) previously.
>>>>
>>>> Ian, will you rebase dpdk-latest onto current master?
>>>
>>> Yes, I'll look at this today. I know when I look last week there were a
>>> few conflicts to be resolved. So will sort these.
>>
>> Hi Ilya, just started looking at this again, are yu sure it's a rebase we
>> want here i.e. rebase dpdk-latest on master?
>>
>> Essentially we what I'm seeing is as the dpdk-latest changes are being
>> applied ontop of the least master history all the previous changes in
>> dpdk-latest have to re-applied include changes such as upgrade to 18.08
>> etc. it's just making it a bit messy, especially with some of the HOWL
>> changes we've had on master.


Actually, these patches:

    7f021f902bb3 ("netdev-dpdk: Upgrade to dpdk v18.08")
    270d9216f1ed ("netdev-dpdk: Set scatter based on capabilities")
    bef2cdc8f412 ("netdev-dpdk: Fix returning the field of malloced struct.")
    73c1a65167fc ("redhat: change variable used for non-root user support")
    eb485f60ce44 ("dpdk: Update to use DPDK 18.11.")

was already incorporated into:

    03f3f9c0faf8 ("dpdk: Update to use DPDK 18.11.")

So, could be just skipped while rebasing.
IIUC, in the end there should be only 2 patches on top of master.
One for meter color and one for rte_ prefix.

>>
>> I'm also think would it not require a force push to the dpdk-latest
>> branch? The re-write of the commit history will change etc.

Yes, this will require the force-push.

>>
>> I know the merge process wasn't ideal from a commit history POV but it did
>> avoid issues such as this in the past. What are your thoughts?
> 
> To provide a better example, what I mean would be if you look at the commit for moving to 18.11 on master, in the commit message we actually use commit IDs form commits to dpdk-latest to reference and help accredit the authorship of work. If we rebase dpdk-latest with master, these commit ID's change in the dpdk-latest branch, meaning in master we have incorrect commit ID etc. in the commit message.
> 
> I guess that’s what I was trying to avoid with the rebase approach and hence why I had used the merge approach (similar to how we used to use dpdk-merge branches).
> 
> Do you have a way around this?

As David suggested we may tag current branch before rebase to not loose
the hashes. However, there was a simple squash of these commits and there
was no important information we could loose. For the future, we could
avoid such issues by using more permanent pointers like mail-list/patchwork
links instead of git hashes from different/unreliable branches.

> 
> Thanks
> Ian
>>
>> Ian
>>>
>>> Thanks
>>> Ian
>>>
>>>>
>>>> Best regards, Ilya Maximets.
>>> _______________________________________________
>>> dev mailing list
>>> dev at openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev