On 12/02/2013 07:16 AM, Adrian Schröter wrote:
Am Sonntag, 1. Dezember 2013, 08:32:47 schrieb Robert
On 11/28/2013 08:49 AM, Stephan Kulow wrote:
The staging model will not catch adverse
interactions reliably. The
reason is that by definition the staging tree is always out of date,
unless the target tree is frozen and after one staging tree is accepted
all other staging trees get rebuilt. This is not conducive to parallel
It depends how you run it. If you have large enough Staging projects, I think
we can build them entirely and merge in factory.
Afterwards we to wait for the other staging projects that right.
But it is a question how many and therefore how large staging projects we have.
Yes, but larger staging projects imply unrelated things having to wait
for each other.
Lets use a simple example. Lets say we have a staging tree that has Perl
and Python in it. Developer A works on Perl stuff and developer B works
on Python stuff.
Developer A upgrades Perl to a new version and things break, developer B
upgrades Python and everything works smoothly. Or the other way around,
I am not being biased. Having both of these in the same staging tree
implies that developer B cannot get the stuff into factory because
something unrelated is busted in the staging tree. Thus, developer B
will be annoyed.
Yes ideally everything would work before pushing things into the staging
tree, but lets just assume we do not live in an ideal world.
The solution to this problem is to split the staging tree, thus we end
up with 2, one for Perl changes and one for Python changes. In this case
developer B does no longer care if stuff in Perl is broken because the
Python staging tree moves forward and gets merged into factory as expected.
This is the root cause for the "ever growing" staging tree problem. Even
if we set out with lets say one staging tree per devel project one will
have the A has to wait on B problem. Look at devel:filesystems. A good
chunk of the stuff there is somewhat unrelated and if you clump it all
into one staging project you end up with the problem outlined in the
"Perl-Python" example above.
In general, this is not a technical problem. With enough build power one
can theoretically have a staging project for everything and push build
times toward an acceptable small time limit. The problem we face is a
people problem. Number of people available to chaperone the staging
projects, number of people continuing to remain interested when their
stuff gets delayed because of some unrelated problem on a relative
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org