qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: Networking patches queue


From: Mark McLoughlin
Subject: [Qemu-devel] Re: Networking patches queue
Date: Thu, 28 May 2009 16:51:13 +0100

On Thu, 2009-05-28 at 10:28 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > Hi Anthony,
> >
> > Recently, Jan has posted 11 networking patches and I've posted 17, so I
> > thought I'd push out a tree with these queued up. Perhaps you want to
> > pull from there?
> >
> > Some notes:
> >
> >    - I've taken the first 6 of Jan's patches, but left 7-11 for now; see
> >      the review comments I just posted. I expect Jan will be able to 
> >      fix them up fairly quickly
> >   
> 
> If the first 6 patches of Jan's series are ready to apply, wouldn't it
> make sense for him to submit that as a separate series?  In the very
> least, I'd like an Ack from Jan before applying his series partially.

I would have thought that was one of the benefits of a clean, bisectable
patch series - that a maintainer could choose to partially apply them.

I know when I send a patch series, I'm fully prepared for that to happen
and would much rather see them applied partially if possible, rather
than re-send the whole series.

(Where partially means 1-N not randomly choosing a subset of patches)

> >    - I've tried my best to fix up the param checking saga by reverting 
> >      Kevin's patch, going with Jan's rollback to something closer to 
> >      what was there originally and applying a small fixup patch
> >
> >    - Not all of these patches are completely isolated to networking 
> >      code - e.g. the fork_exec() patch adds a SIGCHLD handler
> >
> >    - I haven't reviewed the slirp changes in great detail, but they 
> >      look okay at a glance
> >   
> 
> I just got the tail end of your series before heading off on travel on
> Friday.  It still needs review and testing.

Okay, that's perfectly reasonable.

I got the impression you would like (at some point) to be able to have
others to act as a funnel for specific areas. I'm just testing the
water :-)

> Of course, if a patches series included test cases for the functionality
> it was implementing, it would certainly go a far way into reducing the
> amount of time it took to test those patches :-)

That's a funny way of observing "we really should have a networking test
suite".

Would "this tree passes kvm-autotest's networking tests" help matters?
If so, I'm sure that could be organised ...

Cheers,
Mark.





reply via email to

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