On 12/02/2013 02:19 PM, Michal Hrusecky wrote:
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 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.
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 versa :-D
So you are saying Perl and Python would not be in the same staging project, fair enough. Use a different example and think about the basic problem I was trying to illustrate. As soon as more than one package is in a staging project you have the problem I was trying to describe.
...
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.
Every package is potentially problematic to some extend. If we rule out that we are going to have 6k+ staging projects you end up with the basic problem outlined in the example: Developer A ends up in a staging project with developer B and developer A's changes cannot progress because developer B's stuff breaks something. There is no way around this unless every package/developer gets their own staging project. That is not realistic and creates a completely different nightmare of coordination. 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