Am Freitag, 29. November 2013, 00:12:40 schrieb Michal Hrusecky:
Susanne Oberhauser-Hirschoff - 21:06 28.11.13 wrote:
Michal Hrusecky
writes: Susanne Oberhauser-Hirschoff - 18:32 28.11.13 wrote:
* Integration means testing, and testing may be a gate/decision point whether further builds make sense at all (think rings). This tracking of test status is not in the tool. And tests should gate further work based on test status. And tests, automatic or manual, have a smart and a stupid order doing them.
So you would like to see better integration between openQA and OBS?
openQA imnsho is just another flavour of build (as in rpm, kiwi, deb, openQA)
Not now, but probably could be integrated that way.
yes, but it would be just one little part of automated QA. Also, it could be also kept standalone, but scheduled and reporting back in a transparent way with OBS. Anyway, the entire QA stuff would be actually multiple huge projects. Yes, we should approach them, but the more low hanging fruit is IMHO the wanted workflow changes regarding the staging projects. They can used also as input for all kind auf QA systems. So, from what I hear and read we need to decide about * Do we always want to enforce staging projects for all submissions? => Means we need some support to set this up automatically as part of the workflow? * How should it work? Eg. a staging project openSUSE:Factory:Stage:$NUMBER_OR_SRING 1) contains a number of unversioned links to the devel package? + on submission time to factory no merge conflicts will happen - stage project may not finish, because people in devel packe are not aware of it. 2) Or "accepting" a submit request. maybe with multiple actions, into a stage project. Keep working there, maybe directly together with the original submitter and transfer changes from there to factory with another request? + devel package changes can happen independend + we have a similar model already with the maintenance incidents. Just that we would not move binaries, only sources. And we would not need the .openSUSE_X.y extensions for package names. - it introduces a temporary third version of the package sources, which may lead to more merge work. do you see another model? -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org