qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] We need more reviewers/maintainers!!


From: Avi Kivity
Subject: Re: [Qemu-devel] We need more reviewers/maintainers!!
Date: Tue, 13 Mar 2012 16:38:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 03/13/2012 04:00 PM, Anthony Liguori wrote:
> On 03/13/2012 08:40 AM, Avi Kivity wrote:
>> On 03/12/2012 10:27 PM, Anthony Liguori wrote:
>>>> I agree that more maintainers would be good, but we also need
>>>> more people with commit rights.
>>>
>>> I disagree strongly.  Having multiple pushers makes things difficult
>>> and encourages people to push without testing.  Part of what makes
>>> pushing take longer than it should today is that my test cycle takes
>>> at least 1-2 hours and it's not uncommon to have to go through 3-4
>>> cycles of rebasing before being able to push.
>>
>> This really sucks.
>>
>> If testing was automated, we could have a staging branch where
>> maintainers would push patches, they'd get tested automatically and then
>> graduate to master.  The workflow would look something like
>>
>>    git fetch
>>    git checkout staging
>>    git rebase origin/staging
>>    <apply patches, pull trees>
>>    git push staging
>>    <wait>
>>    <staging gets merged into master autoamatically, or you get an email
>> from the test system>
>
> The problem for me with this is that I test before I do a thorough
> review.  I do a quick review, but not a line-by-line review.  So I
> don't necessarily want to queue for push.

Seems to me it's better to review before testing, no?

>
>> If testing cannot be automated, perhaps a lock around the tree would
>> help.
>
> I think merging qemu-test into make check would help a lot.  If all
> committers are running the same test suite before pushing, then this
> problem would become less common.  It's livable now because most
> committers commit infrequently.
>
> But if we added more committers, it would become pretty problematic.

I'm not arguing either for or against that, just trying to make the
commit process more efficient.

-- 
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]