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. > I am assuming the answer is "NO" to my request? In that case I am > planning to add a basic test case of pushing mpls label, traffic > class and ttl and submit final mpls patch with the changes > included. Will this be ok? If yes, I have started adding mpls > related code in ofproto-dpif.at and having some issues when run with > "make check". I Looked at testsuite.dir/<failed test> log files and > didn't get much information from there. Is there a way to debug the > problem associated with code addition in ofproto-dpif.at or is it > the right place to add? What kind of problems do you see? Usually the testsuite.log files are pretty helpful. You can always add more code to dump out more information. Maybe you should show us what you added. > I will do similar thing for vlan-qinq i.e add a basic test case and > submit vlan_qinq patch along with your suggestion. I plan to work on > comprehensive test cases for vlan-qinq and mpls after finishing > both. If this is okay with you please let me know. You can include > mailing list back in your response, since it was a query from my > side I unicasted. The test cases need to be ready at the same time as the code. Otherwise there's no way to tell that it works. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
