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.