On 12/02/2013 07:16 AM, Adrian Schröter wrote:
Am Sonntag, 1. Dezember 2013, 08:32:47 schrieb Robert Schweikert:
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 development.
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 frequent basis. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org