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!

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.

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

Reply via email to