vdas_20130221
by
Marie Anne Bizouard
—
last modified
2013-02-22 00:01
VDAS
1. Announcements
- software alignement organisation [odt]
2. DAQ software issues
- migration CVS-->SVN
- migration CMT-->CMake
- development model (re-)definition
Attendance: Loic, Elena, Franco, Didier, Florent, Benoit, MAB, Frederique
Minutes:
1. software alignment:
MAB: a draft collecting inputs to get organized is on the wiki. Should be circulated among us to be sure we have a well defined plan (scope+schedule to be defined)
Benoit : About schedule when VirgoPolicy will be ready?
Franco: still working with Emmanuel with virgoStaging new procedure. Pm improvement. Set of scripts that could also be used for remote installation.
Benoit: Make it use for general purpose.
Franco: OK. For the moment priority is to install the virgoStaging mechanism @ Cascina, but the use for laptop and remote site could be generalized.
2. Software management
- CVS --> SVN porting
Franco reports the pbs. The main pb is about tags that get all messed up. In SVN repository 3 folders are creating:
/trunk
/tags
/branches
trunk is OK. but tags are all messed up because 1 tag name might be used by 2 or more packages.
A solution would be to import each package in its own repository and then merge SVN repositories. Having 1 repository per package is going to be cumbersome.
Benoit: What about the recursive checkout with SVN?
Franco: CVS/CMT --> SVN/CMT to be tested. A priori the CMT plugin for CMT should work but has not yet been tested. Test the CMT new plugin.
Benoit : can we also define permision for each package?
Franco: yes SVN allows much more flexibility than CVS. Read access for some packages.
Benoit/MAB: Cleanup opportunity?
Franco: Importing only on a snapshot of what is in the CVS repository
MAB: separate repositories sofwtare, users doc, ...
MAB: SVN / alignement synchronisation?
Franco: a priori not needed.
Agreement: Franco will investigate the SVN repository merging option + test CMT/SVN plug in. will contiue to work in parallel with software alignment. Swap when we are ready.
- CMT --> CMake
Benoit : CMake: does package version exist?
Franco : maybe not directly, a la autotool, but there must be ways to define package version.
Loic/MAB: what are the motivations to use Cmake instead of CMT?
Franco: CMT does not allow to generate package rpm, tar balls ... necessary for package distribution. No tools to control test applications results, etc ...
MAB: this prospective work on a possible replacement of CMT by CMake has started many years ago. One of the issue, which is still valid, is the long term maintenance of CMT. A little bit of news I collected this week: ATLAS, still using CMT, is going to take a decision about the tool to management their software in the coming months. Not an easy decision. Main issues with CMT: slow, configuration not always easy and not performant multi-core implementation. Ask LAL to provide either a new tool or to continue developement for CMT. Negociation with LAL. If LAL does not accept the job, there is a chance ATLAS will drop CMT for another tool (maybe WAF?). LHCb is still using CMT but with a CMake layer that end users don't see. CMS is using Scramble (or scrabble?). They proposed other experiments to use the same tool. Not accepted. CERN IT is now providing CMT wrapper package to CERN libs ...
Agreement: need to follow what is happening around CMT and its future developement. Keep activities/tests with CMake, but this is a low priority compared to the alignement/SVN porting/Package distribution/development model. Will follow up on the 4 subjects in the coming months.
AOB:
next VDAS call in 2 weeks. ER3 focus if the run is finished.
- software alignement organisation [odt]
2. DAQ software issues
- migration CVS-->SVN
- migration CMT-->CMake
- development model (re-)definition
Attendance: Loic, Elena, Franco, Didier, Florent, Benoit, MAB, Frederique
Minutes:
1. software alignment:
MAB: a draft collecting inputs to get organized is on the wiki. Should be circulated among us to be sure we have a well defined plan (scope+schedule to be defined)
Benoit : About schedule when VirgoPolicy will be ready?
Franco: still working with Emmanuel with virgoStaging new procedure. Pm improvement. Set of scripts that could also be used for remote installation.
Benoit: Make it use for general purpose.
Franco: OK. For the moment priority is to install the virgoStaging mechanism @ Cascina, but the use for laptop and remote site could be generalized.
2. Software management
- CVS --> SVN porting
Franco reports the pbs. The main pb is about tags that get all messed up. In SVN repository 3 folders are creating:
/trunk
/tags
/branches
trunk is OK. but tags are all messed up because 1 tag name might be used by 2 or more packages.
A solution would be to import each package in its own repository and then merge SVN repositories. Having 1 repository per package is going to be cumbersome.
Benoit: What about the recursive checkout with SVN?
Franco: CVS/CMT --> SVN/CMT to be tested. A priori the CMT plugin for CMT should work but has not yet been tested. Test the CMT new plugin.
Benoit : can we also define permision for each package?
Franco: yes SVN allows much more flexibility than CVS. Read access for some packages.
Benoit/MAB: Cleanup opportunity?
Franco: Importing only on a snapshot of what is in the CVS repository
MAB: separate repositories sofwtare, users doc, ...
MAB: SVN / alignement synchronisation?
Franco: a priori not needed.
Agreement: Franco will investigate the SVN repository merging option + test CMT/SVN plug in. will contiue to work in parallel with software alignment. Swap when we are ready.
- CMT --> CMake
Benoit : CMake: does package version exist?
Franco : maybe not directly, a la autotool, but there must be ways to define package version.
Loic/MAB: what are the motivations to use Cmake instead of CMT?
Franco: CMT does not allow to generate package rpm, tar balls ... necessary for package distribution. No tools to control test applications results, etc ...
MAB: this prospective work on a possible replacement of CMT by CMake has started many years ago. One of the issue, which is still valid, is the long term maintenance of CMT. A little bit of news I collected this week: ATLAS, still using CMT, is going to take a decision about the tool to management their software in the coming months. Not an easy decision. Main issues with CMT: slow, configuration not always easy and not performant multi-core implementation. Ask LAL to provide either a new tool or to continue developement for CMT. Negociation with LAL. If LAL does not accept the job, there is a chance ATLAS will drop CMT for another tool (maybe WAF?). LHCb is still using CMT but with a CMake layer that end users don't see. CMS is using Scramble (or scrabble?). They proposed other experiments to use the same tool. Not accepted. CERN IT is now providing CMT wrapper package to CERN libs ...
Agreement: need to follow what is happening around CMT and its future developement. Keep activities/tests with CMake, but this is a low priority compared to the alignement/SVN porting/Package distribution/development model. Will follow up on the 4 subjects in the coming months.
AOB:
next VDAS call in 2 weeks. ER3 focus if the run is finished.