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
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.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org