[Top][All Lists]
[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.