Participants

Topics

• Plannings next FESA release
  • Integration FESA-Database
    • S. Matthies explained that currently each "deliver" of a class/deploy-unit triggers a new database entry. If the version of the class/deploy-unit already exists in the database, the deliver will fail.
    • This behaviour currently cannot be changed in the lab-specific part of the plug-in. -> To be checked
    • In order to ease testing for classes which are in development, we would like to have the possibility to deliver a class without increasing its version-number at GSI.
    • One approach would be to run a productional and a test-database, where only the productional DB requires a new version per deliver.
    • This issue is not relevant for the current FESA-release, since it only affects the FESA Eclipse plug-in which can be released separately and the DB.
  • Adaption Python codegen
    • The GSI-specific code-generation for properties/value-item successfully was adapted in order to use the new python-codegen-API
    • This was validated by running the GSI-Specific Integration-Tests
  • Eclipse-Luna
    • At CERN the latest Eclipse version Luna was introduced in July
    • It is desired to introduce Eclipse Luna in GSI as well later this year
    • From the FESA plug-in point of view the introduction of Eclipse Luna should be possible with little effort
    • Since the introduction affects the application group as well the change to the latest Eclipse version should be planned carefully
  • RDA3
    • FESA itself is ready for RDA3. Just the integration-classes inside "fesa-core-integration-test" need to be updated. A.Schwinn will take care for that.
    • A.Schwinn will add the classes of "fesa-core-integration-test" to the testplan in the Wiki as soon as the update is finished.
    • V.Rapp will release RDA3 (and all its dependencies) for the GSI-systems in the near future.
  • Multiplexing per BeamProcess/ WR-Timing
    • The connection to the WR-Timing could only be implemented preliminarily. The desired functionality could not be completely tested yet since the timing system itself still was under development.
    • Alex will review the implementation and provide an integration-test in order to test the implementation.
    • The presently defined events for WR-Timing will be requested from the AP-group to be inserted into the next FESA-release.
      • If a FESA-class needs to use a new event which is not yet available in the released list, it should be possible to define it locally, only for this class.
  • Release date
    • It is planned to ship the MCS system by beginning of Oct. to Saclay. This system should run RDA3, so it is needed to install the most recent FESA-release on it.
    • After the FESA-release, but before the shipping all class-developers need to update their classes to the most recent FESA-version
    • As well all GUI's need to be migrated to RDA3
    • So in order to ship the MCS in Oct. we would need to have the next FESA release already by beginning of Sept, so that everybody who is concerned has some time to update his/her MCS-software.
    • Since some features need to be integrated into FESA before a release can be done (see the bullets above ), the release probably will be done later (mid of Sept. ? ) --> as soon as possible
• Discussion Guideline
  • Proposed changes
    • With some minor changes the proposal for chapter 4.2 was accepted (operational FESA-equipment should continue to run on hardware failure )
  • The AP-Team suggested to add a section in the FESA development guideline concerning the usage of datatypes
    • requested is to use double instead of float wherever this is possible (applications only use double types)
    • A.Schwinn will prepare a proposal