On Mon, 2014-02-10 at 04:56 -0500, Dmitri Pal wrote:
On 02/09/2014 11:00 AM, Jakub Hrozek wrote:
> Hi,
>
> as we discussed with the other developers earlier this week, we should
> start using Reviewed-by tag. As a benefit, we would easily see which
> developer understands the code apart from the author without having to
> resort to searching the mailing list.
>
> I tried using the tag when pushing Pavel's recent patch reviewed by
> Stephen, so you can see the result with:
> git log -1 fd520622529e26682eb8fa4c5355db18399c3121
>
> For the workflow, I followed the Samba guidelines pretty much
> completely:
>
https://wiki.samba.org/index.php/CodeReview
>
> Would this workflow work for everybody?
>
> Also, do we gain anything by using Signed-off-by as well? I think we
> wouldn't as the vast majority of patches are written by a single
> contributor, so adding Signed-off-by would be mostly busywork, but I'd
> like to hear other opinions.
>
> When we agree on the workflow, we should add it to:
>
https://fedorahosted.org/sssd/wiki/DevelTutorials
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I think sign-off should be used only in case when a patch originally
created a lot of controversy and required reconciliation between the
patch developer and some opponent(s). In this case IMO the opponent
should sign-off on the final patch agreeing to the approach even though
it might not be a full review. This way later we will be able to see
"who did this" and "who let it happen". ;-)
The signed-off-by tag in the kernel development model just identifies
who created and has the right to contribute the patch.
If multiple developers created parts of the patch there can be multiple
signoffs
Here in paragraph 12 there is the meaning of signed-off-by according to
the kernel policies, and later there are also other tags described:
https://www.kernel.org/doc/Documentation/SubmittingPatches
I think we should not diverge too much from these guidelines or we risk
confusion in the community about what these tags mean.
Simo.
--
Simo Sorce * Red Hat, Inc * New York