On Fri, Mar 23, 2012 at 9:04 AM,  <r.ke...@telekom.com> wrote:
>
>
> -----Original Message-----
> From: Ben Pfaff [mailto:b...@nicira.com]
> Sent: Thursday, March 22, 2012 10:56 AM
> To: Kerur, Ravi
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] MPLS important comments (was: Re: Patch for MPLS)
>
> On Wed, Mar 14, 2012 at 06:17:46PM +0100, ker...@telekom.de wrote:
>> We don't put unfinished code into our repository.  You can make your
>> life easier, though, a couple of ways.  First, there's no need to
>> merge or rebase often.  You don't even have to do it before sending
>> out a revised patch, as long as you let us know what commit it's based
>> on.  Second, if retesting is a problem then it means that the tests
>> aren't automatic enough.  "make check TESTSUITEFLAGS=-j8" runs in 26
>> seconds here, which is not a large burden.
>>
>> <rk> I think we are not in agreement here. I am not saying testing
>> existing OVS functionality is a burden. What I meant to say was mpls
>> tests are not automated yet and I have to go through manual testing
>> on 2 systems to make sure nothing is broken after every
>> merge/rebase. It would be really helpful if I can just work on
>> unit-tests as a separate patch such that it makes it easier and
>> faster to test the mpls functionality. Furthermore, it doesn't break
>> any existing functionality and hence I am making the case.
>
> I'm not putting major new code without unit tests into the repository,
> especially based on the number of bugs I saw in the initial patch (and
> reported).  Sorry.
>
> <rk> Even I wish all software were picture perfect at it's first attempt, 
> unfortunately none of them are.
>
> Usually during the development phase there is a targeted release branch into 
> which code associated with new features are checked-in, tested and later 
> merged into mainline or master before release. 3000 lines of code changes are 
> sitting in my private repository and I was in rebase/retest cycle and wanted 
> to move the code into the targeted release branch so I don't have to rebase 
> everytime. Looks like that's not the case here. Anyways thanks for your code 
> review comments.

Ravi,

I spent some time to test your most recent version of this patch.
Using the very simple test environment that I described before
consisting of just two machines talking to each other with a single
level of tagging I encountered several issues.  These included not
only the hardware offloading issues that I mentioned previously but
also an issue with the bottom of stack bit that prevents non-IP
traffic from passing.  Encountering these types of issues with the
first and most basic experiment that I ran gives me significant
concern about the level of testing that this patch has seen.  I
understand that you might have expectations about common use cases but
the fact is that Open vSwitch and OpenFlow are designed to encourage
new usage models and so it is important that any code we add is robust
in all situations.  Generally, open source projects would not add a
work-in-progress patch and would expect that any patches sent for
review consist of what the author considers a final revision.
Unfortunately, this means without significant improvements we're not
going to able to accept this patch or continue reviewing it (which is
quite time consuming).
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to