DILIGENT TCom

Europe/Zurich
Budapest

Budapest

Notes and Actions
DILIGENT Technical Meeting Budapest, January 15-19, 2007 ------------------------------------------------------------ The meeting was quite productive, split in parallel sessions between small working groups. Short term objectives (by the end of January): - complete the Release Alpha - answer to the reviewers' requests: - give them access to RA functionalities and improved interfaces - initial re-design of the two portals involving the two user communities - the three missing deliverables - produce a new risk analysis and contingency plan. On the base of what will be provided by this deadline they will decide on the need of an additional review. After the integration phase for Release Alpha (RA) (build and deployment test exploiting ETICS) we are now testing it. Even if the RA is due by the end of January the testing will not be completed by the given deadline. The difficulty of this activity has been under estimated and the responsible partner has still to learn about the technology and the system functionality. The meeting was very useful to speed up this process. Additional resources have been allocated to this activity only recently. Nevertheless, by the end of January only partial results will be available. Important improvements and plans for the integration and release of the next versions of the software have been discussed on the base of the current experience gained with RA. Exploitation of ETICS will continue in the same way, some requirements will be raised to the ETICS team. The split and reallocation of responsibilities previously assigned to FhG partner have been agreed and partners are allocating new resources in order to be able to cover the additional charge of work assigned to them. Clearly it will require time for the new members to become productive. Previously produced code seems to be unusable by the partners. Metadata management and one community portal have already been re-designed and are now being re-implemented. The other activities are making good progresses. DILIGENT is planning to be present at the EGEE User Forum and conference. An infrastructure that should host the demonstrators should be set up and joint to EGEE PPS. === RELEASE ALPHA-BETA === RELEASE ALPHA/BETA MEETING DOCUMENTATION ** ACTION1: 100% of Documentation should be made available by the end of Jan RELEASE CANDIDATE ALPHA ** ACTION2: M1.8.2 will include a sentence stating that the RA includes the functionality expected from DoW - for RB we will use the same approach: developers will define their own tasks in Savane ** ACTION3: cancelled components will be included in RB with high priority, a task for each one of them should be created in Savane. ** ACTION4: use bi-monthly meetings and savane to monitor and speed up the integration activity and improve coordination. Monthly WP1.8 status will be sent to the Technical Manager. BUILD PROCESS ** ACTION5: introduce "release candidate" and "released" configurations as frozen configurations. note: authomatic builds could be executed at build time. Subsequenlty deploytest will decide on the need of new builds (at system or subsystem level) during deploytest activity, same for the testing activity that will decide on the need/frequency of new integrations. DEPLOYTEST ** ACTION6: use serviceArchive to syncronise the service Profiles. ** ACTION7: introduce subsystem integration builds in addition to system level build , frequency defined by the "active" activity (build/deploytest/testing). Integration builds at project-level may run without publishing, just to discover incompatibilities. ** ACTION8: gives possibility to manually run a subsystem-level build to CERN to facilitate deploytest. ** ACTION9: Adopt a different approach for startup services (manual deployment) in deployment testing, other services can rely on authomatic deployment and package repository for release BETA. ** ACTION10: Package Repository should support management of different versions/configurations of a service/package to be used for deployment testing of the new release candidate artefacts. ** ACTION11: CERN will support 4DSoft in re-using the deployment testing tool for release Alpha. A new agreement will be decided for Release Beta (reusing the tool/reusing the infrastructure/reusing the deployment of the startup services/...) CERTIFICATION ** ACTION12: Lino will produce a list of certification rules for relase Beta. The Tcom will provide feedback on it, WP1.8 and WP1.7 will decide when and how to implement the certification checking in the release beta process. TESTING ** ACTION13: test plans produced by 4DSoft should be validated as relevant by the developers in order to test DILIGENT as a system (not just independed components). ** ACTION14: input parameters should be provided by the developers to 4DSoft. 4Dsoft will distribute instructions. ** ACTION15: 4DSoft will re-use the test scripts prepared by the developers. ** ACTION16: highest priority will be provided by the developers for the testing activity in the next two weeks. Regular short phone meetings every two days could be organised under request of 4DSoft. 4DSoft should be able to complete the collective layer and test all libraries by the end of January PACKAGING DOCUMENTATION ** ACTION17: adoption of Wiki to collect documentation from developers. UoA will send the proposal to the Tcom. ** ACTION18: UoA will set the Wiki service and documentation structure. ROADMAP TO BETA ** ACTION19: Tagging for Release Beta will be 0.2.x. New configurations for existing components should be cloned from existing ones as 0.2.0. The 0.1.x will be frozen at the end of the testing process as the RELEASED ALPHA version. We may rename the final 0.1.x conficurations to ALPHA. ** ACTION20: Requirement to ETICS would be the possibility to clone configurations and sub-configurations ** ACTION21: By the end of the project the code should be collected in a common repository in order to allow continuity, if foreseen. Deadlines: First integration build 0_2_1: (march19) End of development (march31) RCB: M32 (april30) RB: M34 (june30) Relase BETA will not be a fully featured release (for all WPs). ** ACTION22: WP1.8 will distribute these deadlines, developers will have to submit what is reasonable for them to savane for the release beta deadline. Lino/TCom to review that the submitted tasks reflect the features expected for release beta. ** ACTION23: Release BETA must be based on GT4.1/4.2 ** ACTION24: Only RB will be made available to the users (not RA) on the DILIGENT PPS infrastructure currently running the portals. This will be used for validation in July. ** ACTION25: We could foreseen to include bug fixing (applied to the HEADS configurations to be re-tagged) to the RB till end of June with quick-release cycles. We will take a decision on this after testing activity for RA. At this purpose fix a meeting on March 1-2 between 4DSoft/ENG/CNR/CERN to discuss the "bug fixing release cycle for RB" in Geneva. ** ACTION26: Deadlines for RB in IP3 will be maintained. Lino will review if functionalities could be postponed to Release Final. ** ACTIVITY27: link the infrastructure running the DILIGENT demonstrators to EGEE PPS. ** ACTIVITY28: deplytest for RB could run on the testing infrastructure.
There are minutes attached to this event. Show them.
The agenda of this meeting is empty