Robert Schweikert - 11:42 2.12.13 wrote:
On 12/02/2013 07:16 AM, Adrian Schröter wrote:
Am Sonntag, 1. Dezember 2013, 08:32:47 schrieb
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.
Well, unrelated things shouldn't go into same staging project...
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.
Shouldn't happen unless Python for some strange reason depend on perl and vice
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.
We should not set up Staging project per devel project (devel project is kind
of limited staging project already) but we should setup staging project for
every problematic package.
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org