On 28.11.2013 16:04, Robert Kaiser wrote:
Stephan Kulow schrieb:
There are several problems with the current "everything through devel project" approach we need to solve. Our ideas are just ideas, but I had several discussions in various places and nobody offered a better idea. So we really would like to start with it and I would like to hear your concerns so they can be part of the final solution.
Whenever discussions like this come up, I wonder if pieces from the Mozilla process that I'm so immersed in might apply.
Hi Robert, I'm having a bit of a problem following your thoughts, do you have some URLs describing that process?
In this case, what we're doing with Nightly might have some merit (though of course it's a different scale and not 1:1 anyhow): What Mozilla has that is similar to Factory is the mozilla-central repository, it's the "spinal column" of development where all patches come together and on to integrated testing. We have a few integration repositories now where the actual patches land and automated tests are run against that set of code, let's compare them to the devel repos that feed into Factory. Anything landing there that breaks any automated tests (unit tests, perf tests, etc.) is being "backed out", i.e. reverted, so we get back to a clean state. So only a state of patches that was tested against the whole rest of the product can "stick" and be merged into the main mozilla-central repo. And if anything breaks with the merge, I guess the whole merge will be backed out (due to the set of code, this rarely happens, though - I'd guess that to happen more often with Factory and devel projects). Also, we generate builds the whole time and our automation is rigged to create Nightly builds (I guess that would match the Factory ISOs here) only from the most recent state that passed tests successfully. I'd guess here this would mean that Foo:devel would only get pulled into Factory if it compiles successfully against the current Factory (can we know beforehand if any dependencies on it compile successfully as well?) and gets reverted if it actually does break things when being pulled in (is that possible?). And Bar:devel will only be able to get into Factory when the Foo:devel "merge" has been cleared in either way. That said, I guess merges with a lot of dependencies and breakages there probably will need all the dependency updates to be staged and tested together before they can be merged all together, in a similar way like you described, possibly. The merging of things is at the moment exactly our problem. A gcc update is not a patch you can take in and out, so you have to be *really* careful and try somewhere else. But from what I understand, our goal is not that far away.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org