Based on all the points exposed so far, I have to make a call here, here it goes: - We will indeed split the tests, since the benefits outweight the costs - The virt test will go to its own repo - The other tests will go to their own repo What I'm doing right now is a shot at merging libvirt and kvm test code, so we only keep in the autotest main repo more 'core' code.
Thanks to all of you for your input! Lucas On Mon, Apr 23, 2012 at 3:03 PM, Chris Evich <[email protected]> wrote: > > (Inline quotes removed, look up in thread for history) > > Let me try and summarize all the points so far, let me know if I got > this right. Also trying to collapse and correspond the points as much > as possible. > > Pro-test separation: > + Hard differentiation between patch-queue's / priorities > for tests separate from core harness code > + New/Updated tests decoupled from core harness code > + Force stability of core harness API > + More Tightly controlled commit/change workflow > + Outside community members would commit more tests due to above > > Anti-test separation: > + Queue/priority management isn't a problem for everybody > + Test/Harness decoupling doesn't depend on separation > + Core API stability can be realized w/o separation > + Increased workflow would burden small (core) team > + Outside community members would commit same or fewer tests > due to above > > Did I mis-word or leave anything out? How about some input from other > people (we won't bite, I promise)? > > -- > 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 -- Lucas _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
