> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, July 20, 2015 6:42 PM > To: Ouyang, Changchun > Cc: Xu, Qian Q; Stephen Hemminger; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue > > 2015-07-20 06:18, Ouyang, Changchun: > > Another thing burst into my thought. > > Can we think more about how to setup a mechanism to block those > patches which causes critical regression issue? > > Yes. Non-regression tests are needed. As it must be done with many > hardwares and many configurations, it must be a shared effort. > As a first step, you can run some automated tests by yourself and > *manually* raise errors on the mailing lists. When it will work well, we could > discuss about gathering test reports in a clean distributed way. > Note that this topic is already a work in progress by few people and a public > proposal should be done in few weeks.
That's good. > > > I did review that patch before, but fail to realize it will break the basic > function of virtio PMD, it is my bad. > > (Can I send the nack to that patch even after it has been merged into > > dpdk.org?) > > After being approved and merged, a nack has no effect. > Having a revert approved is the good way. I have acked Stephen's new patch. > > > After that, we find that in our testing cycle, we spend time in > > investigating that and root the cause, and sent out the fixing patch on > > July 1. > Keeping virtio basic functionality broken more than 20 days is bad thing for > me. > > It wouldn't be so long if these 3 simple things were done: > - use a better title: "virtio: fix Rx from Qemu" instead of a not meaningful > "fix > the vq size issue" > - cc Stephen (I did it later) who did the original patch you wants to revert > - have an acked-by from Huawei Xie who commented the patch > > > If we can run a regression automation test with every patch set sent > > out to dpdk.org, and put those patches breaking any test cases Into > > failing-list and notify author, reviewer and maintainer, all those things > should be done before theirs being merged, then it will prevent from > merging the erroneous patch into mainline, and thus reduce most reverting > patch. > > As explained above, it is planned and you can start running you own local test > machine. But please do not spam the mailing list with automated mails from > these tests.