[Meego-qa] Where to put test packages?

[Zheng, Jeff]

Personally agree. This way we can follow meego distribution process at http://wiki.meego.com/MeeGo_Release_Creation#How_the_code_reaches_the_Trunk.2FRelease.

Some questions:

1. Can we define criteria that all test suites should pass the build in the test project, especially for mcts? 
2. Do we need support specific version of component or just support latest version of component? I suggest that we only support latest version of component in MeeGo. For example, if connman changes API, mcts-connman-tests should change accordingly and integrate into obs immediately after connman integration. For old release like meego 1.0, we can upload test packages to a website, and thus not necessary to support it in OBS

Bests
Jeff

> -----Original Message-----
> From: meego-qa-bounces at lists.meego.com
> [mailto:meego-qa-bounces at lists.meego.com] On Behalf Of Timo H?rk?nen
> Sent: Tuesday, December 28, 2010 2:36 PM
> To: Wang, Jing J
> Cc: meego-qa at meego.com
> Subject: Re: [Meego-qa] Where to put test packages?
> 
> On Tue, 2010-12-28 at 05:07 +0200, Wang, Jing J wrote:
> > Mcts definitely is just one project as it currently be. I mean other test suite
> such as ux test will be in another project. Anyway, all test packages will be in
> same repo, but I don't think Trunk:Testing is a good place. When user do
> Trunk image testing, he have to add Trunk:testing repo for installing test
> packages need. It may cause chaos when install other packages in Trunk.
> >
> > jwang
> 
> Test suites can use their own obs projects for development, I understand
> that but I'd still like to see one repo having them all. Just like the
> process for any other package in MeeGo. Let's take mcts as an example
> where the work flow would be something like:
> 
> 1) individual developers work on the tests in their home:
> 2) current unstable version lives in devel:mcts
> 3) stable release goes into the tests -project (e.g. Tests:Testing or
> something) - This project has only few users the review the incoming
> packages.
> 
> This would introduce the same quality control as with any other packages
> to the test packages. The spec files, dependencies, etc. would be
> checked before accepting them into the stable tests repo. This would
> help to avoid situations where test packages break image builds or
> simply won't work.
> 
> BR
> 
> -Timo
> 
> >
> > -----Original Message-----
> > From: Mu, Qin
> > Sent: Tuesday, December 28, 2010 10:58 AM
> > To: Wang, Jing J; Timo Härkönen; meego-qa at meego.com
> > Subject: RE: [Meego-qa] Where to put test packages?
> >
> > Yes, dedicated repos for test suites are definitely helpful to efficiently
> setup test environment.
> > If one project is to be created for each test suite, there might be better to
> created a umbrella project to cover all those test suite sub-projects. Many
> repos otherwise have to deployed to test device and difficult to maintain.
> > Alternately, we create just one project, e.g. Testing:MCTS, to hold all
> released test suites as packages.
> >
> >
> > Qin, Mu
> >
> > -----Original Message-----
> > From: meego-qa-bounces at lists.meego.com
> [mailto:meego-qa-bounces at lists.meego.com] On Behalf Of Wang, Jing J
> > Sent: Tuesday, December 28, 2010 8:32 AM
> > To: Timo Härkönen; meego-qa at meego.com
> > Subject: Re: [Meego-qa] Where to put test packages?
> >
> > Yes, we really need a formal place to hold test packages. I have felt
> inconvenient in automated testing if there is no such test repo. Option 2 is
> good, but I guess one new project is not enough, maybe we need several
> test project which can 1:1 map to current test suite.
> >
> > jwang
> >
> > -----Original Message-----
> > From: meego-qa-bounces at lists.meego.com
> [mailto:meego-qa-bounces at lists.meego.com] On Behalf Of Timo H?rk?nen
> > Sent: Monday, December 27, 2010 9:27 PM
> > To: meego-qa at meego.com
> > Subject: [Meego-qa] Where to put test packages?
> >
> > Hi
> >
> > I've been thinking about this a bit and we have a couple of options how
> > to do this. Currently test packages seem only to live in different
> > people's obs home projects which of course is not the way to do it.
> >
> > So here's my take on how they could be handled:
> >
> > 1) Push all the test packages into Trunk via Trunk:Testing just like
> > everything else going into MeeGo.
> >
> > 2) Create a new project (e.g. Tests:Testing) for core and other tests
> > that are run regularly in automated testing - packages that are not tied
> > to specific versions of components in MeeGo. Having them in some other
> > project would make them faster to deploy and easy to add on top of any
> > image just by adding that repo. Tests that are written for applications,
> > libraries, etc. would still go the trunk path since they are tied to
> > that specific version and need to be in the same place as the software
> > that they are written for.
> >
> > personally I'd prefer option 2 but in any case we need have test
> > packages somewhere else than in people home projects - hopefully sooner
> > than later.
> >
> > Thoughts?
> >
> > BR
> >
> > -Timo
> >
> > _______________________________________________
> > MeeGo-qa mailing list
> > MeeGo-qa at lists.meego.com
> > http://lists.meego.com/listinfo/meego-qa
> > _______________________________________________
> > MeeGo-qa mailing list
> > MeeGo-qa at lists.meego.com
> > http://lists.meego.com/listinfo/meego-qa
> 
> 
> _______________________________________________
> MeeGo-qa mailing list
> MeeGo-qa at lists.meego.com
> http://lists.meego.com/listinfo/meego-qa