(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