Choose timezone
Your profile timezone:
DILIGENT Release Final Meeting
→
Europe/Zurich
ENG, Rome
ENG, Rome
Description
Planning for Release Final integration and testing
Please find below the main actions and decisions that were produced from the very fruitful meeting that we held in Rome. They do not represent minutes of the meeting – since all discussions and motivations that driven us in taken these decisions are not reported – and they are presented in different order with respect the meeting sessions. Finally, they are draft since CERN, 4DSoft, and ENG could amend this list of actions.
Beta Testing
The testing of the Beta release will continue until the end of August. This is motivated by two main factors. First, 4DSoft will gain further experience and will continue to familiarise with the complex gCube framework; moreover, all procedures that we will put in place for the Beta release will be reused for the final and this will allow to be sure having enough time to test the Final RC as scheduled in the DoW. Second, most of the code is the same and therefore the bugs identified in Beta will be fixed in Final directly.
The program to complete the test of the Beta release is quite full. We agreed to prepare the spreadsheet that it is attached to this email and 4DSoft prepared it very quickly. All partners have to specify the clients that can be used to test what is specified in this spreadsheet and the data sets that are needed as input. For example, we are preparing collections (subset of real ones) of data and metadata that will be used to feed the content, the metadata catalog, and xml indexer together with the script required to perform these operations. Then we need the script required to feed the indices. At the end, we will have in the testing infrastructure enough data to test the system as a whole.
As far as the testing infrastructure, 4DSoft will install 6 new DHN Beta. On these set of DHNs all services will be deployed. All partners will support such activity as much as possible in order to have everything running in the 4DSoft servers. This means that 4DSoft will try to deploy the services following the available documentation and use the dynamic deployment functionality. If a fail will occur or if special (manual) actions have to performed to bootstrap the service, the service provider will be contacted and the credentials to access that server will be provided in order to give them the chance to manual solve the problem. The same applies to the portal installation (supported by ENG) and portlets bundle (supported by UoA and CNR).
Final RC Testing
The testing of the Final RC will start on September immediately after the delivery of the RC. A plan similar to the one attached to this email will be prepared.
Achieving the Final RC (FRC)
All partners have to specify in Savane a task for each component they will deliver in the Final release of the gCube system. The name of the task must be the same of the name of the component in Etics. Each partner must create a 0.3.0 configuration for each component and subsystem it is responsible for. A unique 0.3.0 configuration will be created for the Diligent project.
<<IMP>> The creation of the Savane tasks and the Etics configuration has to be completed before the next Tcom. <<IMP>>
This could appear as a short notice request, but it was already requested a number of times in the past and it is required to have concrete discussion at the next Tcom.
As far as the Collective Layer, we have decided to release at the end of July a stable version of the components that currently are part of the Beta. All known bugs and limitations will be removed. The DHN FRC, the DIS FRC and the Keeper FRC will be released at the beginning of August. This will allow to perform the integration and deploying test in accordance with the DoW during August and release the FRC at the beginning of September. This mainly means that
NO delays are envisaged at this stage
All components must be released as planned in the DoW starting from the beginning of August. They will be progressively integrated and tested.
At the beginning of August, I will send an email to the ExCom to inform the main board of the project about missing components with respect to the ones that we have planned in the detailed design documents.
At the beginning of September, I will ask the ExCom to analyse the list (if not empty) of the delayed components that have not be included in the FRC.
Please notice that the Keeper FRC will not manage post-redeployment reminiscence and intelligent bootstrapping. We conveyed that it is too risky to introduce such important (but extremely advanced) functionality as official part of the FRC. However, following the decisions that will be taken from the Tcom next week, CNR will work on this functionality after the release of the FRC and plans to release an advanced version of the Keeper components later on. This will represent an extra achievement (since it was never officially planned) that we want to release to prepare the ground for future activities. We will discuss also with other partners that intend to deliver an advanced version of their components and with them will work on a brunch of the gCube system.
Measuring the quality of the FRC
In order to improve the quality of the software that we are preparing, we have decided to establish at least two metrics on the gCube source code. Details about these two metrics will be provided at the next Tcom. For the TopN components that will appear on the lists ordered in accordance with these metrics, a bug will be open and monitored. This should allow the project to progressively improve the quality of the code and of the documentation.
There are minutes attached to this event.
Show them.
