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. 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. This is just from my POV as someone who has been immersed in the Mozilla process for a long time, but I have never done distro stuff and I see how 1) Mozilla's release engineering / CI system is probably unmatched in scale (even though OBS is awesome) and 2) a distro has a completely different scale in terms of the amount of code and build times involved. Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org