Deliverable Review Form
Identification of the deliverable or milestone |
Project: EMI |
Deliverable or milestone identifier: D3.4.2 |
Title: DSA1.4.2 - Annual Maintenance and Support Report |
Doc. identifier: EMI-DXXX-CDSREF-Title-vx.x |
Author(s): A. Ceccanti |
Due date: 30.04.2012 |
Identification of the reviewer |
Name: Tiziana Ferrari |
Affiliation: EGI |
EMI Activity/External project or Institute: |
Review date |
mm/dd/yyyy |
Author(s) revision date |
mm/dd/yyyy |
Reviewer acceptance date |
mm/dd/yyyy |
Attach the reviewed document to the deliverable page, put here a link
General comments
25/05/12 Tiziana
I reviewed document DSA1.4.2-v0.pdf
-
SQAP: meaning of acronym? Glossary section is empty?
- "The Debian 6 porting activity was also started but wasn’t completed for all products in time for the EMI 2 Matterhorn release"
- the lack of GGUS support in tracking of SLA violation is mentioned as a problem in the executive summary. Was this a show stopper? The executive summary seems to put a lot of emphasis on this problem.
Later on the document says: SLA violation warnings were introduced in GGUS in February 2012. So is the needed feature now available in GGUS?
The release of a GGUS report generator is expected in 2012 and a prototype is planned for September 2012.
- what is the reason for ARC to be able to fix medium priority bugs more quickly than immediate priority fixes?
- Figure 5 Number of submitted problems in year two per product: why such a high value for dcache? the corresponding number of solved problems is relatively small (figure 6)
- figure 6: what is the reason for having in figure 6 more solved problems then the number of sumbitted problems? is this due to the fact that in PY2 you are counting probblems already submitted during PY1?
if this is the case, then it would be nice to have data in figure 5 also for Py1
- debian support: the lack of prioritization of this activity when compared to other development, maintenance and support activities: is it really lack of prioritization, or the assignment of a low priority to this activity?
- Coordination of the EMI Beta and Acceptance Testing activities, to provide early access to EMI software to interested parties.: what is the impact of beta and accetance testing activities of EMI? how many partners profited from the early access?
- conclusions: part of the conclusions section (first half of the page) seems a copy of the executive summary. The section can be simply rephrased "Future work" and the duplicated text removed (no need to repeat text already available in the exec summary).
Additional recommendations (not affecting the document content, e.g. recommendation for future work)
Detailed comments on the content
Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described
N° |
Page |
Section |
Observations and Replies |
Is Addressed? |
1 |
xx |
x.y |
Sequence of comments and replies separated by twiki signature and date |
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
|
4 |
|
|
|
|
|
Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.
--
FloridaEstrella - 24-May-2012
--
FloridaEstrella - 24-May-2012