On Tue, 2010-12-28 at 09:19 +0200, Zheng, Jeff wrote: > 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 >
We should. At least I'd expect that they compile without problems and can be added to an image without hacking and problems. From tests like mcts-x-tests et all in the tests repo the latest version would be used in testing. If there's a need to have older packages we can create branches or figure out other means to support those activities. The main thing IMO is to get this thing moving. Related to that we could use Tools:Testing project to hold the tests so we wouldn't have to request a new one. Tools:Testing project's gatekeepers are currently me and Sampo Saaristo. Joonas Kylänpää is going to take over it though. He's going to start handling tools and tests integration (beginning of next week AFAIK). Getting tests in there is pretty much the same as getting packages into Trunk:Testing. 1) Follow the MeeGo packaging policy - might need some exceptions like what groups to use, etc. I'm sure things will sort out once we start doing it. 2) Make sure it works in devel: project 3) submitrequest to Tools:Testing from the devel: project (not from home:) and have a reference to a bugs.meego.com id in .changes to tell why this package is added/updated 4) if rejected - fix it and resubmit people who have submitted packages to Trunk:Testing should be familiar with the process. If in doubt, ask. If there's no objections we could start doing this right away since the missing test packages are a bit of a problem for automated testing. I'd think they're a problem for other things too.. BR -Timo > Bests > Jeff > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Timo H?rk?nen > > Sent: Tuesday, December 28, 2010 2:36 PM > > To: Wang, Jing J > > Cc: [email protected] > > 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; [email protected] > > > 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: [email protected] > > [mailto:[email protected]] On Behalf Of Wang, Jing J > > > Sent: Tuesday, December 28, 2010 8:32 AM > > > To: Timo Härkönen; [email protected] > > > 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: [email protected] > > [mailto:[email protected]] On Behalf Of Timo H?rk?nen > > > Sent: Monday, December 27, 2010 9:27 PM > > > To: [email protected] > > > 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 > > > [email protected] > > > http://lists.meego.com/listinfo/meego-qa > > > _______________________________________________ > > > MeeGo-qa mailing list > > > [email protected] > > > http://lists.meego.com/listinfo/meego-qa > > > > > > _______________________________________________ > > MeeGo-qa mailing list > > [email protected] > > http://lists.meego.com/listinfo/meego-qa _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
