DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Min Hu (Connor)" <humin29@huawei.com>, dev@dpdk.org
Cc: Luca Boccassi <bluca@debian.org>,
	Kevin Traynor <ktraynor@redhat.com>,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	David Marchand <david.marchand@redhat.com>
Subject: Re: [dpdk-dev] [PATCH] net/hns3: use the correct HiSilicon copyright
Date: Fri, 2 Apr 2021 09:07:55 +0100	[thread overview]
Message-ID: <6c726d96-422d-61e0-0128-3622eb70aca7@intel.com> (raw)
In-Reply-To: <8ac461ed-021d-a017-fa79-167782df0247@huawei.com>

On 4/2/2021 2:45 AM, Min Hu (Connor) wrote:
> 
> 
> 在 2021/4/1 22:45, Ferruh Yigit 写道:
>> On 4/1/2021 9:53 AM, Min Hu (Connor) wrote:
>>> According to the suggestion of our legal department,
>>> to standardize the copyright license of our code to
>>> avoid potential copyright risks, we make a unified
>>> modification to the "Hisilicon", which was nonstandard,
>>> in the main modules we maintain.
>>>
>>> We change it to "HiSilicon", which is consistent with
>>> the terms used on the following official website:
>>> https://www.hisilicon.com/en/terms-of-use.
>>>
>>> Fixes: 565829db8b8f ("net/hns3: add build and doc infrastructure")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Fixes: e31f123db06b ("net/hns3: support NEON Tx")
>>> Fixes: c09c7847d892 ("net/hns3: support traffic management")
>>>
>>
>> Is backport not requested intentionally?
>>
> Yes, we think this is just spelling bug, which does not affect
> functionality, so there is no need to backport.
> 
> By the way, Is there any standard for which patch should be backported?

We are backporting fixes, unless the fix doesn't apply to an old version 
somehow, like some patches fixes problems coming from external components, like 
problem comes with new version of FW that is not used by LTS code etc..., these 
doesn't need to be backported to old versions.

Personally I am for backporting as much as possible, even syntax changes, 
because in long term they may cause conflicts and cause trouble merging actual 
fixes. Also for someone who gets a diff between latest and LTS version code, it 
helps to reduce the noise.

cc'ed LTS maintainers for more authoritative response, at the end of the day 
they get the patches to the stable trees.

>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>
>> <...>
>>
>>
>> .


  reply	other threads:[~2021-04-02  8:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  8:53 Min Hu (Connor)
2021-04-01 14:45 ` Ferruh Yigit
2021-04-02  1:45   ` Min Hu (Connor)
2021-04-02  8:07     ` Ferruh Yigit [this message]
2021-04-06  0:57       ` Min Hu (Connor)
2021-04-06  0:57 ` [dpdk-dev] [PATCH v2] " Min Hu (Connor)
2021-04-06 16:29   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c726d96-422d-61e0-0128-3622eb70aca7@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=bluca@debian.org \
    --cc=christian.ehrhardt@canonical.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=humin29@huawei.com \
    --cc=ktraynor@redhat.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).