>>> The RTEMS project has currently nothing to sign. >> >> Signed-off-by: >> >> is standard Linux kernel patch practice to declare that >> sender is the author or the patch or he proves other >> source (sender of patch) to be compliant with project license >> - GPL and that he passes patch in mainline direction >> in the maintainers hierarchy. It has nothing to do with >> assignment or other paperwork. So usual practise >> is that each developer and maintainer in the path >> to mainline adds his/her "Signed-off-by" approval >> before commit to his tree or send to other maintainer >> >> https://www.kernel.org/doc/Documentation/SubmittingPatches >> >> But I have nothing to omit this for RTEMS if it is >> not considered good practice. > >I think this Linux policy is very useful. Unfortunately the discussion of >commit message formats in RTEMS was not very fruitful up to now. I'm thinking the current understanding as far as licensing goes with RTEMS is we look at the license on the patch file, and assume if it's posted to the email the permission has been given to commit... so signing off for licensing purposes may be extra... I'm not sure if it would be more technically difficult to commit a signed patch (if the developer went above and beyond) either, so long as unsigned patches were accepted as well... although, there might be other reasons to sign off...
On a slightly different note: I'm a little curious, about rebaslined patches, for example: if I rebaselines a 4.10.2 patch written by DH for submission against the head, what would be the recommended commit message for the patch? I would like to annotate that DH wrote the original patch, but in this scenario I would also like to annotate that I rebaselined the patch... Would we want to consider adding who reviewed patches as part of the commit message? Would that be technically feasible? How would we want to format the commit message in that case? > >-- >Sebastian Huber, embedded brains GmbH _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
