[Cosmo-dev] Re: [Scooby-dev] Issue with same tools in multiple products.

Mikeal Rogers mikeal at osafoundation.org
Wed Jun 7 19:36:20 PDT 2006

Hash: SHA1

On Jun 7, 2006, at 7:13 PM, Mike Taylor wrote:

> I can see the issue you are talking about but I feel another issue  
> will happen if we move the testing tool to a new location.  We  
> would have to treat it like an external project and bring into play  
> all that would entails:
> 	- project space (svn, docs, etc)
I should be writing more docs anyway :)
> 	- release cycle
> 	- testing across all products for each release
We already do interop of all products for each release as they relate  
to that release.
> 	- updating Cosmo and Scooby for each new release
I don't know exactly what you mean by this?
> Currently I don't know if HTTPTest is ready for that and I wonder  
> if the time spent doing the above equals the time maintaining two  
> copies (knowing that it will be merged later).

Well, I would argue that we could load up HTTPTest with a few more  
requirements and release it in a week or so, along with TestObject  
which it uses.

The test tools based on HTTPTest, DAVTest and JSONTest aren't ready  
for release, but those are both specific to cosmo and scooby so they  
can easily stay in those repositories.

> Part of my concern is that having it as a standalone project will  
> force Cosmo's HTTPTest to worry about Scooby's HTTPTest  
> requirements and vice-versa and that may be premature.

Right, which we would need to reconcile via a short and simple  
release cycle for the tool.

> Once the OSAF Eco-system Testing Tool has been defined and setup as  
> it's own project then I think we can take the two HTTPTest parts  
> and the Chandler test framework part and start figuring out how to  
> merge them.

I agree that if the solution to the problem causes more issues than  
we have working around it then we should just wait. But if it's  
simpler or as difficult I think we should do it now, both as a trial  
for when all the tools use a common framework, and to begin to define  
a new process that we're going to have to deal with some day anyway.

There are also some advantages to solving the problems now. We open  
up the testing tools in a much better way to community contribution,  
we speed up the QA groups ability to write tools in their own  
repository --- stabilize them -- then move them into the product so  
that we don't ship release quality products that include unstable  
tools. And I think loading QA with greater requirements of release  
quality tools, documentation and transparency is a good thing and  
should be a higher priority in the group.

I think we could take this out of the context of just QA tools as  
well, we could define a repository and process for all tools we  
create that aren't part of our major projects, and have a mail list,  
bugzilla category, repository and community around those tools --  
this could include the Kagami tool you're currently writing for example.

> On Jun 7, 2006, at 9:51 PM, Mikeal Rogers wrote:
>> So we have a good problem, well good that we're far enough along  
>> that it is a problem.
>> As we're nearing end to end testing across the products we've  
>> quickly started to use the same tools and frameworks in multiple  
>> products. Since traditionally our process has been to keep  
>> functional testing tools in each products svn repository we've  
>> encountered some technical and process issues.
>> 1.) People working on a given tool or framework may have different  
>> commit privileges in one product than another.
>> 2.) If a tool or framework is used in two products then we have to  
>> do two separate commits and maintain all the same files in two  
>> repositories.
>> Our current issue is that a tool I originally wrote for cosmo,  
>> HTTPTest, is now being used by adam to develop a tool for scooby  
>> testing, JSONTest. Since it lives in the cosmo repository he can't  
>> commit changes to it and I can't easily merge his changes in while  
>> I'm working on the same files to extend testing for cosmo.
>> Going forward we will be writing a very large framework that will  
>> be used by nearly every tool OSAF QA uses to test all products so  
>> this issue needs to be solved in a broader context than just our  
>> current problem with HTTPTest.
>> I'm open to any and all ideas for solving this problem.
>> -Mikeal
>> _______________________________________________
>> scooby-dev mailing list
>> scooby-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby-dev
> ---
> Bear
> Build and Release Engineer
> Open Source Applications Foundation (OSAF)
> bear at osafoundation.org
> http://www.osafoundation.org
> bear at code-bear.com
> http://code-bear.com
> PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29
> _______________________________________________
> scooby-dev mailing list
> scooby-dev at lists.osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby-dev

Version: GnuPG v1.4.3 (Darwin)


More information about the cosmo-dev mailing list