On 07/31/2013 10:40 AM, 686f6c6d wrote:
On Tue, Jul 30, 2013 at 7:08 PM, Robert Schweikert <rjschwei@suse.com> wrote:
A simple example:
Lets say component A depends on component B. Component A is released as version 1 (A-1) and component B is also released as version 1 (B-1). Now component team B decides to have release number 2 (B-2) and thus component team A gets notified. Component team A can now create a branch of component A and start building against B-2. If the changes to get A-1 to build against B-2 are trivial and A-1 can work with both B-1 and B-2, component team A merges the changes back from the branch and tags A-1 as working with B-1 and B-2. If the changes to A are extensive component team A may decide to have a new release, tag it as release 2 (A-2) and tag it to be working with B-1 and B-2 or only with B-2 if that is the case.
What if A-2 isn't ready in time for release, but A-1 doesn't work with B-2? - Do you punish the "bleeding edge" worker bees of component B by including the ancient B-1 together with A-1?
The team working on component B has an incentive to help the team of component A to get there. Also consider that we have the same situation today, what if gcc48 staging is not ready to go into Factory in time, then we have to release with gcc47. Today the incentive for others to work in gcc48 staging is non existent, therefore you end up with only a couple of people working on it.
- Do you punish the "stable, time-tested" worker bees of component A(-1) by only including B-2 and dropping A(-*) from the release?
Again, the basic situation is no different than today, if a package does not build with the stuff that is in Factory and the maintainer does not fix it and Stephan has better things to do the package gets dropped. Whether it is time tested and was in the previous release are secondary considerations. In the component model people working on B have an incentive (self interest) to help people working on A to move forward, or both might disappear.
- Multiply this by a zoo of 5 or say, 26 components A-Z, and this will get real messy and a lot of integration time will be needed before release. - "Yay, we where able to release component Z-2 just-in-time for release, so it works with the most recent versions of components A to D. Sadly, components H-i to M-j don't work with Z-2 anymore."
I think what is intended to be used together should be build and tested together. Or am I overlooking something? Am I overestimating the testing and integration effort?
The more one has to integrate at once the harder it is and if the incentives for participating in the integration work are low few people will participate. These are both symptoms we observe today. As Stephan puts it "no one cares about Factory" == low participation in the integration work. In a component model the incentive to help others that work on components one depends on are built in. But there are most likely other solutions, we just have to find them. Creating incentives (self interest), distributing responsibility, and autonomy are the underlying principals that I believe can work. In our current model incentives are low, no self interest to work on Factory, autonomy is low, you get gcc when someone else decides you get it, and responsibility is low, people do not feel responsible for Factory. You cannot fight human nature, or as Michal pointed out in another reply in this thread "we are mostly selfish beasts, so we do take a care about our own stuff". And maybe it can be as simple as presenting the data differently as Michal proposes. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead 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