Re: AMD/IOMMU: revert "SR56x0 Erratum 64 - Reset all head & tail pointers"

[George Dunlap <george.dunlap@eu.citrix.com>]

On 06/04/2013 10:53 AM, Ian Campbell wrote:
> On Tue, 2013-06-04 at 10:38 +0100, George Dunlap wrote:
>> In this context, I would read "Acked-by" as "I agree that this should go
>> in", or at very least, "I am happy for this to go in"; whereas to me
>> "Reviewed-by" to me sounds like, "I took a close look at the code and
>> didn't see anything wrong, but otherwise have no opinion on the matter."
>
> I think we decided (somewhat informally I think) that we interpreted
> Foo-by according to Linux's Documentation/SubmittingPatches:
>
>          If a person was not directly involved in the preparation or handling of a
>          patch but wishes to signify and record their approval of it then they can
>          arrange to have an Acked-by: line added to the patch's changelog.
>
>          Acked-by: is often used by the maintainer of the affected code when that
>          maintainer neither contributed to nor forwarded the patch.
>
>          Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
>          has at least reviewed the patch and has indicated acceptance.  Hence patch
>          mergers will sometimes manually convert an acker's "yep, looks good to me"
>          into an Acked-by:.
>
>          Acked-by: does not necessarily indicate acknowledgement of the entire patch.
>          For example, if a patch affects multiple subsystems and has an Acked-by: from
>          one subsystem maintainer then this usually indicates acknowledgement of just
>          the part which affects that maintainer's code.  Judgement should be used here.
>          When in doubt people should refer to the original discussion in the mailing
>          list archives.
>
>          [...]
>
> Reviewed-by is somehow more formal:
>
>          Reviewed-by:, instead, indicates that the patch has been reviewed and found
>          acceptable according to the Reviewer's Statement:
>
>                  Reviewer's statement of oversight
>
>                  By offering my Reviewed-by: tag, I state that:
>
>                   (a) I have carried out a technical review of this patch to
>                       evaluate its appropriateness and readiness for inclusion into
>                       the mainline kernel.
>
>                   (b) Any problems, concerns, or questions relating to the patch
>                       have been communicated back to the submitter.  I am satisfied
>                       with the submitter's response to my comments.
>
>                   (c) While there may be things that could be improved with this
>                       submission, I believe that it is, at this time, (1) a
>                       worthwhile modification to the kernel, and (2) free of known
>                       issues which would argue against its inclusion.
>
>                   (d) While I have reviewed the patch and believe it to be sound, I
>                       do not (unless explicitly stated elsewhere) make any
>                       warranties or guarantees that it will achieve its stated
>                       purpose or function properly in any given situation.
>
>          A Reviewed-by tag is a statement of opinion that the patch is an
>          appropriate modification of the kernel without any remaining serious
>          technical issues.  Any interested reviewer (who has done the work) can
>          offer a Reviewed-by tag for a patch.  This tag serves to give credit to
>          reviewers and to inform maintainers of the degree of review which has been
>          done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
>          understand the subject area and to perform thorough reviews, will normally
>          increase the likelihood of your patch getting into the kernel.
>
> Acked-by is supposedly something which is offered by the maintainer of
> the relevant code to indicate they are happy for it to go in. In the
> Linux world that might be via a different maintainer's tree (for cross
> subsystem stuff) or be an indication from e.g. a driver maintainer to
> the subsystem maintainer that the patch can be applied. In the Xen world
> I think we interpret an Ack from someone in MAINTAINERS as a signal to
> the committers that the patch should be committed.

I stand corrected.

  -G