Recently in QA and release engineering we've noticed that a lot of
small tools that have been or are currently being developed don't
directly belong in one of the three main projects we have at OSAF
(Chandler, Cosmo, Scooby).
Examples of such tools are the Cosmo test tools (TestObject and
HTTPTest) which are also going to be used for testing scooby
(inherited by JSONTest). Another example is bear's recent project
(Kagami). And going forward we see a lot more tools being written
that follow the same trend.
The main issue is that these tools either belong in multiple project
repositories or in none of our current project repositories. Also,
the tools are usually developed with a commiter list different than
that of the main project (example: commiter for HTTPTest may not be
commiter for Cosmo)
We are defining tool as any project that doesn't contain any product
specific code. Example: HTTPTest would be a tool, but the scripts
written for testing cosmo would still remain in the cosmo repository.
We obviously can't treat each tool as it's own project, giving it
isn't own list, repository, etc. So it was proposed that we create a
"tools" project, which could be used as a catch-all for the various
projects that come under this category. The tools could be developed
in this repository and commiter rules governed by the maintainer's of
the tool (obviously following the larger OSAF commiter guidelines).
We could also use the "tools" list to discuss issues that don't
directly affect the main projects.
The largest implication in all of this is probably the fact that some
of the tools for testing some projects are going to become
dependencies of that project since they live outside the project's
repository. Which means tools have to be on a release cycle and
versioned.
In QA we're ready to commit to a release cycle for all tools and a
new policy that all main product (Chandler, Cosmo, Scooby) releases
go through a test cycle using only released tools.
Note: CATS does not fall under tools because it does not meet the
requirement of containing no product specific code.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general