> >>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,
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 <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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
