(Partial) Transcript of Workshop 1,  Thursday, Sep 4, 13:45 - 15:15

Topic: Configuration Management for a Program Family
By: Eric Dubuis

Introduction, Case A)

Given a single program P then it is rather easy to make several releases
of it:
- develop the program on the main trunk of the version control system
- make a branch for the current release Ri, prepare the release, and 
eventually merge back changes
- repeate the above two steps for every new release

If there is a bug in one of the releases R1, R2, ... then:
- go to the respective branch
- fix it (you may introduce a new branch leaving from the current one)
- eventually merge changes with the main trunk


Program Family, Case B)

Given a program family PF = {P1, P2, P3}. The programs Pi shall use the 
following components:
P1 = {C1, C2}
P2 = {C1, C2, C3}
P3 = {C1, C2, C4}


Having One Main Trunk Only, Case C)

If the programs P1 to P3 are all derived from one and only one main 
trunk by introducing
the respective branches then case C) occurs, see picture.

Scenario: After having released P1 to P3, a problem is discovered in 
component C1.

Problem: With this scenario, one has to go to every respective branch, 
fix the problem
related with C1, and make a new release R1', ..., R3', respectively. And 
you have to merge
one of the fixes back to the main trunk. As the number of programs 
grows, this scenario does
not scale.


Alternative Solution, Proposed by Ralph Johnson, Case C)

- Introduce a main trunk for each of the components Ci, 1 <= i <= 4.
- Introduce a main trunk for each of the programs Pk, 1 <= k <= 3. The main
    trunk for a program contains the information of how it is composed.

If, say, component C1 needs to be fixed after programs P1 to P3 were 
released
then the following needs to be done:

- If every program works fine with the latest version of every component Ci:
    o fix C1 leading to C1'
    o create P1', P2', and P3' such that these programs use C1'
       (probably on the respective main trunk, details omitted)
- If the programs required the exact version of a component Ci then,
    for each program Pk requiring C1':
    o create a new branch for Pk'
    o codify in that branch that C1' is now used
    o create Pk'


Some Comments from Workshop Participants

Nicolai Josuttis:
- In large systems it is often more useful to have individual copies of 
a given
    component for every service
- features are not components and vice versa

Ralph Johnson:
- Some people keep utilities, libraries, and tools within the version 
control system
- One large company performs repeated builds to verify compatibility with
    third party components which might have changed

Unknown (Urs?).
- What if there are new requirements for C1 which are in conflict with 
the old ones?

All: Then we got a problem...

Eric Dubuis:
- Does this scale, i.e., for the case of a large set of C's?

Ralph Johnson.
- If the C's are libraries, yes this would scale

Nicolai Josuttis:
- Questions the scalability of the above presented approach
- Suggests that sometime the versions are made explicit, i.e., in the 
name of the component
- And, as mentioned already, prefers copy & paste (i.e., code 
repetition) for large systems

Ralph Johnson:
- There is a need of a system that finds copies, i.e., repeated code