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.
I'm talking about
1. support _manual_ steps in the flow: hardware tests in the community are manual, not automatic. bluez audio comes to mind.
Hmmm, looking at the chart, we really have pretty much automatic everywhere. Maybe we should weaken it so it wouldn't look like manual testing is not possible. But manual testing is slow and if we want to get packages through fast enough and with limited resources, everything should be as automatized as much as possible. And most of the manual testing happens once it gets at least to Factory integration part.
2. clearly distinguish test from build: a failing test may still mean an ok package, just only 'gold', not 'platinum'
Currently it is. It's independent service. That's also why there is a QA team in workflow (teams can overlap in real world). To interpret/fix results.
However how will this help dependent multi-target projects (like gnome, or kde or databases or d:lang:*) to likewise be stable at all^wmost times?
It looks to me like the flow that is proposed here continues to break projects that build for both factory and other released distributions.
Few comments:
* It will not break stable versions * Changes done in devel project should be send to Factory anyway ** If changes are in Factory, base is not going to change to break everything without fix provided
Sooo, the solution is simple, if you want your stuff not getting broken as nobody know what you have, submit your changes to Factory and don't keep them to yourself :-) Devel projects are packages on the way to Factory anyway ;-)
Like an upstream project at random times would push their stuff into my working branch and break it "because I'll merge it upstream later anyhow" ;-)
All changes to Factory would still have to go through devel project. So nobody can break your stuff. There might be updates of some (build) required packages, but in that case, it shouldn't brake your previous version and when is the better time to know about new incompatibility than when you are updating package already anyway. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org