> On Feb 17, 2017, at 10:48 AM, Yigit, Ferruh <ferruh.yi...@intel.com> wrote:
>
> On 2/17/2017 4:34 PM, Wiles, Keith wrote:
>>
>>> On Feb 17, 2017, at 10:21 AM, Yigit, Ferruh <ferruh.yi...@intel.com> wrote:
>>>
>>> On 2/17/2017 3:43 PM, Keith Wiles wrote:
>>>> Calling strncpy with a maximum size argument of 16 bytes on destination
>>>> array "ifr.ifr_ifrn.ifrn_name" of size 16 bytes might leave the
>>>> destination string unterminated.
>>>>
>>>> Signed-off-by: Keith Wiles <keith.wi...@intel.com>
>>>
>>> net/tap: fix possibly unterminated string
>>>
>>> Coverity issue: 1407499
>>> Fixes: 6b38b2725cdb ("net/tap: fix multi-queue support")
>>> Cc: sta...@dpdk.org
>>>
>>> Applied to dpdk-next-net/master, thanks.
>>>
>>>
>>> (Updates:
>>> - patch title:
>>> It is preferred to mention from problem solved instead of the tool that
>>> found it.
>>>
>>> - Added coverity tag:
>>> This helps to trace coverity issues, defined syntax is:
>>>
>>> Coverity issue: xxx
>>> Fixes: yyyy
>>>
>>> - Added Cc: tag for stable tree:
>>> In case stable tree wants get this patch, to make patch visible.
>>
>> I agree this is good, but to many rules not listed or checked in the tools.
>> We need a much easier method to submit patches in the format that is defined
>> and checked.
>>
>> Today it is way to hard to know every little internal format for every type
>> of patch. We need to fix this problem to make it easier to submit patches to
>> dpdk.org, we can not continue like this as we grow it will become way to
>> much work for the repo maintainers and the submitter.
>
> That is why I am documenting what has been changed and the reasoning in
> the mail, so I am hoping this is helping others that following the mail
> list sync about rules. Also gives a discussion medium about rules..
Great, but we need to document this on the web site not in email. We can not
expect someone (or a new person) to read millions of emails to find these
hidden gems, right?
>
>>
>> Using a better tool then submitting via email seems like a better solution
>> as long as we can add the given checks to the tool. Using a tools should
>> also reduce the email traffic for most everyone, but we need to allow anyone
>> to ask for all of the commits to the repo or pull requests like patches.
>>
>> How can we handle these types of issues in the future?
>>
>>> )
>>
>> Regards,
>> Keith
Regards,
Keith
