[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v7][PATCH 00/16] Fix RMRR

>>> On 16.07.15 at 10:13, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> It looks like most of the libxl/libxc patches have been acked.  It
>>>>> seems to me that most of the hypervisor patches (1-3, 14-15) are
>>>>> either ready to go in or pretty close.
>>>> Now that I looked over v8 I have to admit that if I was a tools
>>>> maintainer I wouldn't want to see some of the tools patches in
>>>> with just an ack, but without any review.
>>> I'm somewhat confused at this point.
>>> Acked-by: is often used by the maintainer of the affected code when that
>>> maintainer neither contributed to nor forwarded the patch. It is a
>>> record that the acker has at least reviewed the patch and has indicated
>>> acceptance.
>>> Does this imply this is already reviewed?
>> No, that would be expressed by Reviewed-by. Acked-by merely
>> means no objection by the maintainer for the change to go in.
> Sorry I'm trying to dig into this.
> If nobody would like to take a look at this, so isn't this the 
> associated maintainer's responsibility to review finally? In this case 
> isn't Acked-by fine enough?

Acked-by is good enough for a patch to go in, yes. Note that I
didn't make this a requirement (as I'm not the maintainer), I just
said that if I was the maintainer, I would for at least some of the
tools patches. And no, it is not the maintainer's role to do a
review if no-one else did - that's why (s)he can ack it as an
alternative, implying (s)he trusts the author without further

> Or you still want to us add two lines explicitly,
> Reviewed-by: A
> Acked-by: A

We generally take Reviewed-by as a superset of Acked-by, so two
tags by the same person are not needed. And (as said elsewhere
recently) ack-s by non-maintainers generally don't count much.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.