>On Fri, 24 Apr 2015 10:32:32 +0000 >"Kavanagh, Mark B" <mark.b.kavan...@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.kavan...@intel.com> >> >>> Signed-off-by: Panu Matilainen <pmati...@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, 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 <ran...@developer.example.org> [lu...@maintainer.example.org: struct foo moved from foo.c to foo.h] Signed-off-by: Lucky K Maintainer <lu...@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@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
