Present: Milosz, Federico, Philippe, Zoltan, Andre, Marko, Hamza, Joel, Wojciech, Chris
Remote: Luisa, Andrei, Hideki, Daniela, Simon
The first part of the meeting was dedicated to listing what factually is creating troubles. Only these written in the slides were discussed. There was a general agreement on all of them, so I refer you to the slides for exact content.
The second part (as important as the other) was to reckon that there is a lot of progress being done on all those topics, and we should pursue this way.
The last part was dedicated to the propositions contained in the slides and meant to help (if not solve) the issues mentioned earlier. The outcome of the discussions is bellow:
A script, potentially dirac-install, should be able to do what dirac-install does, but with parametrized input: there should be no hardcoded urls, but the default. This will allow to test easier the integration branch, or to test various combinations of extensions, externals and LcgBundle, without the need to make releases.
It is not clear whether this will go through dirac-install directly, or if we need a new script, because dirac-install does more than just installing. Some technical ideas were thrown, but we decided to keep it for further offline discussion (plugin-based, similarity with pilot bootstrap problem, dirac-install-++, etc).
It was agreed that Zoltan will take care of the implementation
This is the top priority task
It was acknowledged that we have a lot of dead code, deprecated features, deprecated options, etc. This pollutes the code and the configuration. We agreed on a strict policy:
This requires methodology:
It was agreed that new features should now be implemented in parallel of the existing code, but disabled by default with a configuration flag. This way the two codes co-exist, and the new one can be merged earlier as technology preview. Taking it out of the technology preview is just another milestone task.
Making sure that there is a flag, and that the changes are well encapsulated become part of the review process.
It was agreed that for PR targeting the release branch, they should be merged as soon as the tests have passed and the PR was reviewed OK. It is asked to developers to do their PR as topical as possible.
The merging of PR into integration should still be done carefully.
There is a general consensus that there are in general 4 roles/uses cases, and that they should have dedicated part in the documentation:
* user: the users of a VO
* Admins: people installing and managing a DIRAC installation
* Experts: people who wants to know more about the internal behavior of and relations between components
* Developers: the code documentation
This already exists, but the content is not matching the description. It needs a revamp.
Chris to write a first proposition and circulate it to iterate over.
This topic is way too long to be addressed in a meeting shared with other topic. A lot of progress were done lately, but they are the result of individual efforts. We agreed on having a separate discussion in order to define a few key points for the evolution of our tests:
* what to test and how
* mocking strategy
* what automation should be done
* etc
The proposition consisting in developing against integration and propagating backward instead of forward did not reach an agreement. Keep going forward for now