On Thu, Mar 29, 2012 at 9:55 PM, Carsten Munk <[email protected]> wrote: > > When having received a proposed change into Mer (through gerrit), and > having done some basic core checks based on the built sources and > packages, the Mer process would then signal to vendors, based on two > 'subscriber lists', one for early notification, after 24 hours, it > would be signalled to the rest. > > The idea here was that we could catch breakage issues early with > vendors like virtual machine adaptations, automated tests on reference > hardware people chose to contribute to early notification, before > activating the full QA from everybody contributing QA work (after 24 > hour), thus saving QA bandwidth of the Mer vendor community. > > The other side was also that vendors could very early report to the > Mer project that changes causes regressions on their own combinations > of Mer + hardware adaptation + potential UI, giving us the ability to > move fast and release the core as 'stable' each time. It would also > give maintainers the ability to quite quickly assess if a change > should go in or not. > > As well as having the benefit that the same tools/systems that sits in > the early notification lists, are the same systems that companies can > use to test their Mer products well -- ie, we use same tools as > vendors would, in Mer itself. Including a new device for testing would > be a matter of subscribing it to the Mer notification feeds for QA. > > Wild dreams here could also be to have vendors contribute test > coverage statistics of their own test sets, so we could assess how > much of Mer gets tested through, through vendor's 'personal' test > cases as well. It also makes for good marketable values to have a > proven quality core. > > Since Mer itself, the description of the core, is change controlled, > we would apply similar QA methods to new releases/package pickups > (when changes are merged, they also need integration)/etc. >
I like the idea that Mer would offer tools and a way how the vendors can attach their Mer product and devices to the QA system, specially using the same process for the package changes and Mer releases. How do you see, should Mer also offer some basic tests or define the test content to the early notification vendors? Meaning that how can we make sure that the tests are update to date and the vendor’s QA result is valid? We can discuss in the meeting what is needed and what kind of tools we could use. And what is needed in the process, example defining what kind of QA types we have, like package change, pre-release, package pickup and release (if this is even needed). -E-P
