[ovs-dev] [PATCHv3] DPDK: add support for v2.0.0

Kavanagh, Mark B mark.b.kavanagh at intel.com
Fri Apr 24 14:04:05 UTC 2015


>
>>On Fri, 24 Apr 2015 10:32:32 +0000
>>"Kavanagh, Mark B" <mark.b.kavanagh at intel.com> wrote:
>>
>>>
>>> >
>>> >On 04/23/2015 11:58 PM, Kavanagh, Mark B wrote:
>>> >> Hi all,
>>> >>
>>> >> Just a quick poll: are the resolutions to review comments in this
>>> >> patch acceptable to
>>> >everyone?
>>> >>
>>> >> If I've missed anything, or are there any additional opens that
>>> >> need to be addressed
>>> >before it can be merged, just let me know.
>>> >>
>>> >> Thanks in advance,
>>> >> Mark
>>> >>
>>> >>>
>>> >>> Update relevant artifacts to add support for DPDK v2.0.0
>>> >>> - INSTALL.DPDK.md
>>> >>> - travis build script
>>> >>> - acinclude.m4: add 'mssse3' flag to OVS_CFLAGS
>>> >>> - netdev-dpdk: fix build with unified offload types in DPDK v2.0.0
>>> >>>
>>> >>> Note that this breaks compatibility with DPDK v1.8.0
>>> >>>
>>> >>> v1: - update DPDK version & build instructions in INSTALL.DPDK.md
>>> >>>     - update DPDK version and remove compile flags in
>>> >>> travis/build.sh
>>> >>>     - fix build with unified offload types in DPDK v2.0.0
>>> >>>
>>> >>> v2: - add mssse3 flag to OVS_CFLAGS in acinclude.m4
>>> >>>     - reinstate '-Wno-cast-align' compile flag for clang
>>> >>>     - add details of vhost user support limitations to
>>> >>> INSTALL.DPDK.md
>>> >>>     - refactor travis/build.sh to reflect these changes
>>> >>>
>>> >>> v3: -correct minor typos in commit message
>>> >>>
>>> >>> Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>>> >>> Signed-off-by: Panu Matilainen <pmatilai at redhat.com>
>>> >
>>> >It feels a bit strange to have signed off something I hadn't seen
>>> >before this (unless it refers to the actual code change) but maybe
>>> >I'm just unfamiliar with the signed-off protocol.
>>> >
>>>
>>> Hey Panu,
>>>
>>> I included you in the 'signed-off-by' field, due to your earlier
>>> contribution re fixing the build with DPDK 2.0 unified rss hash types
>>> (http://openvswitch.org/pipermail/dev/2015-March/052022.html).
>>>
>>> Contributing.md states 'If the patch has more than one author, all
>>> must sign off'; however, maybe in this case it would have been best
>>> to allow you to review the patch first, and then you could have
>>> signed off when satisfied with the patch in its entirety. Given that
>>> you had previously contributed a subset of the content (which,
>>> incidentally I had -1'd at the time), I felt it prudent to include
>>> you in the tag, rather than leave it open to misinterpretation
>>> regarding the origin of the code.
>>>
>>> Any clarification the maintainers could provide on this matter would
>>> be greatly appreciated for future reference.
>>
>>I am not the maintainer but I can tell that you can carry on signatures
>>of all the authors of the original work with their consent, of course.
>>
>
>Hi Fabio,

Apologies for the typo here Flavio.

>
>Thanks for your feedback. The point you've made here really is the crux of the issue in
>question: whether to include another's name in a signoff tag, without their consent, or
>not. Using this patch as an example: Panu previously proposed changes which were rejected
>at the time, but were later integrated into a patch that I submitted. In order for him to
>receive credit for his contributions, I added him to the patch's signoff. However, this
>could potentially carry the connotation that he had approved/signed off on the entire
>patch; conversely, if I had omitted his name, it could potentially be perceived that I had
>attempted to pass his code as my own. So, what to do?
>
>The Linux kernel submission guidelines
>(https://www.kernel.org/doc/Documentation/SubmittingPatches) specify the following
>procedure, which, while slightly different from this scenario, are IMO equally applicable:
>
>	If you are a subsystem or branch maintainer, sometimes you need to slightly
>	modify patches you receive in order to merge them, because the code is not
>	exactly the same in your tree and the submitters'. If you stick strictly to
>	rule (c), you should ask the submitter to rediff, but this is a totally
>	counter-productive waste of time and energy. Rule (b) allows you to adjust
>=>	the code, but then it is very impolite to change one submitter's code and
>=>	make him endorse your bugs. To solve this problem, it is recommended that
>=>	you add a line between the last Signed-off-by header and yours, indicating
>	the nature of your changes. While there is nothing mandatory about this, it
>	seems like prepending the description with your mail and/or name, all
>	enclosed in square brackets, is noticeable enough to make it obvious that
>	you are responsible for last-minute changes. Example :
>
>	Signed-off-by: Random J Developer <random at developer.example.org>
>	[lucky at maintainer.example.org: struct foo moved from foo.c to foo.h]
>	Signed-off-by: Lucky K Maintainer <lucky at maintainer.example.org>
>
>Is this approach amenable? If so, I can upload a patch for CONTRIBUTING.md
>
>Thanks,
>Mark
>
>>There might be feedbacks during the review process, so if you agree with
>>the feedback and change the patch, it is expected that the reviewer
>>will look at it again to make sure the issue has been addressed
>>properly.  Then if he agrees, he will sign that specific patch version.
>>
>>If some other patch version happens next, that previous review signature
>>is lost. The reviewers are supposed to look and sign again.
>>
>>There's the case where the reviewer don't want to sign anything and just
>>provide feedbacks.
>
>Sure - the 'reviewed-by' tag may be added at the discretion of the reviewer.
>
>That's why we ask for the standard tags like
>>'signed-off-by' or 'reviewed-by' lines so that the intention is clear.
>>
>>The maintainer will grab all the patch's signatures and apply to the
>>patch when merging it to the repo.
>>
>>fbl
>
>_______________________________________________
>dev mailing list
>dev at openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev


More information about the dev mailing list