* Chris Evich <[email protected]> [2012-07-26 11:05:25]: > On 07/26/2012 06:18 AM, Alex Jia wrote: > > I think autotest also have Todo list, it's public and shared with autotest > > guys and fans, > > maybe, we can update it then you may take some for you. Perhaps Chris has > > better idea. > > > > Thanks for your contribution and effort again, > > Alex > > > > > > Thanks. > > > > Red Hat / Fujitsu / IBM teams, > > I think a libvirt TODO list is a fantastic idea! How about I put a list > up on the virt. autotest wiki? That way everyone can edit and put > status, notes, etc. next to each item. I think this would help > coordination across companies and teams. Thanks Yu for the suggestion!
Autotest wiki is a better place. > > Since it's a VERY small group responsible for libvirt code review - > basically myself, lmr, cleber and Alex (THANK YOU!!!), this is the main > bottle-neck. i.e. Your team of 4+ people, plus IBM team, plus other > people, all sending code to only 1-3 people to review! > > The problem is we want to keep code quality high, and this is mostly > dependent on peer-review (nobody can get first-time 95%). Also, lmr and > I both just came back from vacation, so the backlog is HUGE :( However, > reducing this backlog is my main focus for this week. > > ---- > > Regarding new test/code review I have an idea/suggestion: > > IIRC, code review time is geometrically proportional to the amount of > code, but exponentially proportional to it's complexity. > > What I propose is instead of large, complete, and multi-part patch-sets. > We (as a group) work more incrementally, sending more frequent, but > smaller patches with only small changes/additions. As am experiment, I > tried this technique recently with my client/shared/xml_utils & > xml_utils_unittest: > > First I submitted new files + very minimal code (1 or 2 base classes and > tests). While I wait for review, I work on other things. After review > + making changes, I add little bit more code, and send up again for > review again. Repeat until "good enough". > > Afterward, I would estimate the submission-review-change cycle was only > about 1 day (sometimes less). The entire xml_utils and > xml_utils_unittest was complete in about three weeks total, plus I got > other work done while I waited for review. > > What do other people think? Could this "more frequent, but small patch" > method work and help us get new libvirt autotest code reviewed and > committed faster? Please share your feedback, even if you think it's > bad idea. sendning all patches related to each command once make sense. such that its helpfull for reveiwers also. > > Thanks! > > -- > Chris Evich, RHCA, RHCE, RHCDS, RHCSS > Quality Assurance Engineer > e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 > _______________________________________________ > Autotest mailing list > [email protected] > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
