Issues identified/Brainstorming

1. Should we rename it to be Bigtest?
2. Test artifact contract
   1. Since one of the basic premises of iTest is that it separates deployment concerns from test execution, most of test artifacts expect to be told about the world they live in. Things like where components are located, what URLs to hit, etc. For now this is very ad hoc and you have to read the test source code to understand what environment needs to be created for the test, what properties need to be passed to it and what kind of knobs it lets you tweak. It would be nice if we can come up with some mechanical approach to specifying and satisfying those types of dependencies.
3. Packaging test data separately from individual tests
   1. It would be very nice to start packaging common test data in artifacts of their own
   2. We need to push package manifests into stand alone artifacts, so that we can have separate ones for different use cases (Bigtop, CDH, etc.)
4. Execution via Maven
   Our entry point into a JUnit test executor is via Maven's fail-safe plugin. This seems to be suboptimal because of a number of concerns (although we're by no means suggesting to abandon the dependency management that Maven artifacts provide - the principle that everything is a Maven artifact with explicitly defined dependencies still stands):
   1. Maven's tendency to "download the internet"
   2. an extra level of indirection between test artifacts and test execution
   3. difficulty formulating include/exclude lists
5. Test composition, test result querying
   1. It would be very nice to have an ability of on-the-fly test-suite composition based on environment, etc.
   2. It would be nice to be able to have a DB-like tool to store results from the test runs and be able to query, track and manipulate them.
6. Lack of an ability to write "distributed" tests
   One major area that iTest is currently missing is an ability for a test to trigger arbitrary actions on any node within a cluster. There used to be Herriot that is perfect for that type of thing, but it is not currently fully integrated into new Maven based build system of Hadoop. We might need to come up with some kind of solution for things like testing HA, etc.
7. We lack docs, FAQs, Tutorials big time
   This creates a barrier of entry for contributing new tests

Plan of attack

1. Wing Yew and I will take a crack at #2 and report the results back in a week.
2. Andrew and I will start looking into Gradle as a potential replacement for Maven as an execution tool and report results back in a week.

Everything else is up for grabs!