Lines Matching full:by
324 Signed-off-by: Random J Developer <random@developer.example.org>
327 将会自动完成。撤销也应当包含“Signed-off-by”， ``git revert -s`` 会帮你搞定。
332 作者签署之后的任何其他签署（Signed-off-by:'s）均来自处理和传递补丁的人员，但
336 何时使用Acked-by:，CC:，和Co-Developed by:
339 Singed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。
342 那么他们可以要求在补丁的变更日志中添加一个Acked-by:。
344 Acked-by: 通常由受影响代码的维护者使用，当该维护者既没有贡献也没有转发补丁时。
346 Acked-by: 不像签署那样正式。这是一个记录，确认人至少审阅了补丁，并表示接受。
347 因此，补丁合并有时会手动将Acker的“Yep，looks good to me”转换为 Acked-By:（但
350 Acked-by：不一定表示对整个补丁的确认。例如，如果一个补丁影响多个子系统，并且
351 有一个来自某个子系统维护者的Acked-By:，那么这通常表示只确认影响维护者代码的部
358 Co-developed-by: 声明补丁是由多个开发人员共同创建的；当几个人在一个补丁上工
359 作时，它用于给出共同作者（除了From:所给出的作者之外）。因为Co-developed-by:
360 表示作者身份，所以每个Co-developed-by:必须紧跟在相关合作作者的签署之后。标准
361 签署程序要求Singed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通
362 过From:还是Co-developed-by:表明。值得注意的是，最后一个Singed-off-by:必须是
371 Co-developed-by: First Co-Author <first@coauthor.example.org>
372 Signed-off-by: First Co-Author <first@coauthor.example.org>
373 Co-developed-by: Second Co-Author <second@coauthor.example.org>
374 Signed-off-by: Second Co-Author <second@coauthor.example.org>
375 Signed-off-by: From Author <from@author.example.org>
383 Co-developed-by: Random Co-Author <random@coauthor.example.org>
384 Signed-off-by: Random Co-Author <random@coauthor.example.org>
385 Signed-off-by: From Author <from@author.example.org>
386 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
387 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
390 使用Reported-by:、Tested-by:、Reviewed-by:、Suggested-by:和Fixes:
393 Reported-by: 给那些发现错误并报告错误的人致谢，它希望激励他们在将来再次帮助
397 Tested-by: 标签表示补丁已由指定的人（在某些环境中）成功测试。这个标签通知
400 Reviewed-by：根据审阅者的监督声明，表明该补丁已被审阅并被认为是可接受的：
406 通过提供我的Reviewed-by:标签，我声明：
422 问题。任何感兴趣的审阅者（完成工作的人）都可以为一个补丁提供一个Reviewed-by
424 当Reviewed-by:标签由已知了解主题区域并执行彻底检查的审阅者提供时，通常会增加
427 一旦从测试人员或审阅者的“Tested-by”和“Reviewed-by”标签出现在邮件列表中，
432 Suggested-by: 表示补丁的想法是由指定的人提出的，并确保将此想法归功于指定的
468 - 上述的 ``Signed-off-by:`` 行，也将出现在更改日志中。
542 Signed-off-by: Author <author@mail>