qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qemu-iotests: make a few more tests generic


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] qemu-iotests: make a few more tests generic
Date: Fri, 10 Jul 2009 15:10:56 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> This problem has already be found. Avi's patch from almost three weeks
>> ago fixes it.
>>   
> 
> Christoph posted an alternative patch and there didn't seem to be a 
> consensus on the thread about what solution was the best one.  See 
> http://article.gmane.org/gmane.comp.emulators.qemu/46032/match=block+clean+up+after.
>   

I know. I really don't care which one is used, but I want to have that
bug fixed.

> It's also up to the submitter to keep track of their patches.  If they 
> think one should be applied that hasn't been, they need to follow up on 
> it.  The only way to scale here is to push as much work as possible to 
> the outer-most nodes.

We can try to help here, but we need to know what you want the process
to look like. When do you want us to resend patches? When no patches
have been submitted for two weeks, I hesitate to resend a patch that is
only a week old. You don't want to be flooded with resends of patches
that you have already taken care of or that you have planned to act on
later, right?

>> It really starts to get annoying. How am I supposed to work with commits
>> only every other week (which is bad enough) and then patches are
>> forgotten and probably won't be merged before another two weeks? I guess
>> I should manage some local tree with fixes myself and move away from
>> basing my work on git master...
> 
> Complaining is all well and good but it doesn't help the problem.  Your 
> particular compliant is about a patch that fixes a problem another patch 
> introduced.  Greater patch velocity == greater instability because there 
> isn't an adequate amount of testing going on.  It takes time to do 
> proper testing and review of patches.

Well, yes and no. If a few patches come into git master each day and a
patch breaks something (and the breakage is really annoying), we'll most
probably have the fix on the next day. On the other hand, if the patches
are two weeks in your queue first, maybe it's a bit less likely that
they break things, but if they do the breakage persists until the next
big patch round comes two weeks later.

Also with each day of patches not committed we're more and more likely
to post patches that apply on master but conflict with your queue.

I would really like to see your queue flushed more often (it has been
flushed more frequently in the past, so why did this change in the first
place?)

> It would be very helpful if you proactively tested/reviewed patches on 
> the mailing list and then commented appropriately.  People adding 
> Tested-by tags to patches on the list would be a great help for instance.

I'm trying to do my share here. If some formalized things like Acked-by
or Tested-by tags are more helpful than "Looks good to me" comments, let
me know.

Kevin




reply via email to

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