Minutes of the CMT Workshop

  1. Issues discussed in the context of the talk of JE Campagne
  2. Issues discussed in the context of the talk of RD Schaffer
  3. Issues discussed in the context of the talk of J. Hrivnac
  4. Issues discussed in the context of the talk of P. Mato
  5. Issues discussed in the context of the (remote) talk of Toby Burnett
  6. Issues discussed in the context of the (remote) talk of David Quarrie
  7. Discussion on SC2/RTAG issues
  8. Specific question of the Interface packages
    1. Last minute brainstorming
  9. Specific question of the directory structure
  10. Various items

1 - Issues discussed in the context of the talk of JE Campagne

PPT slides - PDF slides

2 - Issues discussed in the context of the talk of RD Schaffer

PPT slides - PDF slides

3 - Issues discussed in the context of the talk of J. Hrivnac

PDF slides

4 - Issues discussed in the context of the talk of P. Mato

PPT slides - PDF slides

5 - Issues discussed in the context of the (remote) talk of Toby Burnett

PDF slides

6 - Issues discussed in the context of the (remote) talk of David Quarrie

PPT slides - PDF slides

7 - Discussion on SC2/RTAG issues

Fons describes the expectations of the SC2/RTAG activities, and the goals for common project management. The OpenSource approach should play a major role in all management practices for the common projects.

About configuration management tools, he distinguishes the activities for the common projects themselves from the experiment activities. Common projects will likely select one common tool (or likely a set of common tools) while they may simply advise a set of recommended tools for the experiments.

A set of standard questions will form the base of an evaluation process for the candidates (At least SCRAM and CMT) concerning the features and the support of the product.


8 - Specific question of the Interface packages

PPT slides - PDF slides

An action plan is settled down which includes:

8.1 - Last minute brainstorming

It appears that after some discussions off-workshop, there might be a solution to the problem of the version naming scheme. This consists in introducing a new concept in CMT : the package semantics. The first example of application of this concept would be the Interface package. The implementation could take the form of a new keyword in requirements file such as (let's select one of these).

interface package ICLHEP

or

package -type=interface ICLHEP

or

package_type interface

            
Then we might introduce a standard macro or statement that would describe the native version tag. The point is that the "cmt show uses" would display this automatically, when the package is understood to be an Interface package..
package ICLHEP
native_version xxx

or

package ICLHEP
macro ICLHEP_native_version xxx

            
and:
> cmt show uses
...
#    use ICLHEP v1r2 native_version=xxx

            


9 - Specific question of the directory structure

It appears, from different sources (David Quarrie concerns, several customers requests in Atlas, discussions reported by Fons, etc...) that the current directory structure enforced by CMT and especially the extra layer of the version directory is perceived as useless or unnatural, resulting in misunderstanding and extra work load.

Long discussions showed that although considering these remarks was absolutely required, many use cases were in favour of the current structuring style. One typical is the Interface Package area were for obvious reasons, it's requested to be able to present all interface packages in different versions simultaneously and individually. In this use case it is probably impossible to organize one global versioning scheme which would characterize an unlikely synchronous evolution of ALL interface packages for ALL projects at once.

Therefore we had a brainstorming session to understand whether a possible solution can be found to offer a mixture the two styles, while maintaining one of the key principles of CMT, which is the specification of the dependency constraints (through the use statement).

The result of this discussion was positive since it seems that we can make the two structuring styles to coexist peacefully. Moreover, it seems that no conceptual nor technical feature of the current CMT should come up to forbid the implementation.

Here are the proposed mechanisms:

Now remains to construct a proper action plan to

  1. express the detailed specifications of the new mechanisms
  2. propose a new design, finding what has to be changed in the current CMT design
  3. propose a temptative implementation
  4. experiment against exisiting projects

According to the available manpower, my very rough evaluation (having rapidly looked at internal technical implications within CMT) results in one man-month for getting a first temptative implementation to test


10 - Various items

PPT slides - PDF slides These less critical points were addressed during the discussion. Most of them were easily agreed on, and should not be hard to implement.