On Fri, 24 Apr 2015 14:04:05 +0000 "Kavanagh, Mark B" <mark.b.kavan...@intel.com> wrote:
> > > >>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 In this case you're not the maintainer. The above is valid when the one merging the patch finds something that needs to be changed because the current tree has changed since posting and merging. So, the maintainer does the small changes needed and adds that small text part to indicate his actions. In our case, there are two contributors exchanging ideas about the patch, so just post the patch with CC to Panu and to be polite tell that he is free to signed off due to his contributions after the '--'. The maintainers should give enough time for the CC'ed folks to review and reply with their signed off or any other tag or no tag as they feel appropriated. When in doubt, ask the person. fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
