[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: KVM call minutes for June 15
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] Re: KVM call minutes for June 15 |
Date: |
Wed, 16 Jun 2010 18:07:23 +0000 |
On Tue, Jun 15, 2010 at 4:13 PM, Anthony Liguori <address@hidden> wrote:
> On 06/15/2010 10:41 AM, Christoph Hellwig wrote:
>>
>> On Tue, Jun 15, 2010 at 08:18:12AM -0700, Chris Wright wrote:
>>
>>>
>>> KVM/qemu patches
>>> - patch rate is high, documentation is low, review is low
>>> - patches need to include better descriptions and documentation
>>> - will slow down patch writers
>>> - will make it easier for patch reviewers
>>>
>>
>> What is the qemu patch review policy anyway?
>
> We don't really have a coherent policy. Suggestions for improvement are
> always appreciated.
I think a policy exists, it's just sort of 'laissez-faire'. But a
clear, written policy agreed by all wouldn't hurt.
Perhaps we should make a checklist or FAQ. I think it should be an
easy task even for someone without much QEMU background to do just
CODING_STYLE or missing SoB checks. Currently there are a lot of
commits with blatant CODING_STYLE violations. Even partial reviews for
specific issues would be helpful.
>
>> There are no
>> "Reviewed-by:" included in the actual commits,
>
> Reviewed-by/Ack-by's are pretty helpful for me. In terms of including them
> in commit messages, if there's a strong feeling that that would be helpful
> then it's something I can look at doing but it also requires a fair bit of
> manual work during commit.
>
>> and the requirement
>> for a positive review also seem to vary a lot, up to the point that
>> some commiters commit code that has never hit a public mailing list
>> before.
>>
>
> That really shouldn't happen and if it does, please point it out on the
> list.
This also happens due to lack of policy.
> Regards,
>
> Anthony Liguori
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to address@hidden
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>