Am Donnerstag, 14. Juni 2012, 20:16:37 schrieb Stephan Kulow:
Am 14.06.2012 19:59, schrieb Adrian Schröter:
gcc is really very special, Richard is already doing test builds of entire Factory
in his own project and I think this going to stay for first testing.
However, afterwards :Staging would define the next transaction to be checked into
That can be either a really deep change (like gcc + last package fixes to be on 100%
but it could be also a step were only leaf packages or packages which should have less
The later case should be faster to test since way less packages need to be build.
However, it would be up to the release manager/team to define this step. Maybe we would
like a "LATER" functionality for requests then, if something is general okay,
but not for this step.
That still is not good enough for me to understand what you
transaction is what? a bunch of submit requests?
basically every package in :Staging would be submitted to Factory and :Staging
would be empty again afterwards.
So devel projects would stay, but SR to :Staging and
from there we copy
it when what happend?
When we say :Staging is okay. No package failing, everything green. Or we say
we take some packages for this transaction.
I guess what I don't understand: how is having
everything in one
:staging an advantage over having everything
in :Factory? I can revert single broken packages right now too - once I
understand where the problem comes from.
The problem is how to fix the problem - if the ruby update only breaks
devel:languages:ruby, but not the packages
in let's say system:management - unless ruby ends up in factory.
hm, that would mean that deeper packages can only be added to :Staging alone
and you need to wait until everything inside depending on it has finished.
I think you will point out now that this may take too long so you need multiple
:Staging in parallel (and the build power for it).
A side note, what I do see here as well is that we may should go back to entire
clean builds at least in these :Staging projects instead only the packages
with source changes ...
SUSE Linux Products GmbH
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org