Identification of the deliverable or milestone | |
---|---|
Project: EMI | Deliverable or milestone identifier: D1.4 |
Title: DNA1.4 - EMI Roadmap and DCI Collaborations | Doc. identifier: EMI-DNA1.4-1277542-EMI_Roadmap_DCI_Collaborations-v0.3.doc |
Author(s): Alberto Di Meeglio | Due date:14/12/10 |
Identification of the reviewer | ||
---|---|---|
Name: O. Smirnova | Affiliation: LU | EMI Activity/External project or Institute: JRA1 |
Review date | 12/12/10 |
Author(s) revision date | mm/dd/yyyy |
Reviewer acceptance date | mm/dd/yyyy |
N° | Page | Section | Observations and Replies | Is Addressed? | ||
1 | 5 | 1.1 | Define term “collaboration” in introduction or elsewhere. Specifically, explain that it refers to a common work of several projects on same product, or to re-use of products of one project by the other in order to optimize effort. It is important to demonstrate that EMI will benefit from such collaborations. -- OxanaSmirnova - 12-Dec-2010 The following paragraph has been added to the Exec Summary of Part 1: "The goal of these collaborations is to define common objectives, perform joint activities, and reuse knowledge and technology produced by either party to optimize effort and speed up the implementation of the objectives. " -- AlbertoDiMeglio - 27-Feb-2011 |
|||
2 | 5 | 1.3 | Please add corresponding deliverable number codes, to simplify reading (as deliverables are often referenced by the codes in the text) -- OxanaSmirnova - 12-Dec-2010 Added -- AlbertoDiMeglio - 27-Feb-2011 |
|||
3 | 9 | 2 | The summary is somewhat excessive; instead of generic text and many references to other documents, it should clearly identify specific collaboration objectives (e.g., as an itemized list), and specific collaboration mechanisms. From the current version it is not easy to extract this information. -- OxanaSmirnova - 12-Dec-2010 The Exec Summary has been agreed to be a summary of the document keeping the same outline of the document itself introducing the reader to what they will find in each section of the document. An itemized list of the collaboration objectives and specific collboration mechanisms are in my opinion a bit out of scope within this document, since they are indeed the main focus of deliverable DNA2.1.1 - EMI Collaboration Programs -- AlbertoDiMeglio - 27-Feb-2011 |
|||
4 | 10 | 3 | Para 1: EMI is not only focused on users; it also aims at reducing costs of infrastructure (DCI) operations, as seen from the text below. -- OxanaSmirnova - 12-Dec-2010 Added a sentence on infrastructure TCO -- AlbertoDiMeglio - 27-Feb-2011 |
|||
5 | 10 | 3 | Para 2: Reference to the Technical Development plan which defines these objectives is needed here -- OxanaSmirnova - 12-Dec-2010 Added -- AlbertoDiMeglio - 27-Feb-2011 |
|||
6 | 10 | 3 | 4th bullet: Unlike the previous 3 areas, this view is narrowed to the collaborations aspect of sustainability, and that is narrowed to commercial companies. Our products must be sustainable even without commercial companies; e.g. GEANT or ROOT are sustainable because user communities support them. -- OxanaSmirnova - 12-Dec-2010 Expanded the paragraph to include the open source communities; However sustainabilty without subsidies means commercial activities; GEANT and ROOT are not really sustainable, they keep getting money from the EC. Of course here my concept of sustainabilty is that the EC contributions can be reduced or even removed. Another definitions for sustainability can of course be that the middleware is so used and necessary that even if nobody is willing to pay for it, the EC has to keep funding it (this is closer to the GEANT modem). This would mean sustainability for the middleware, but I'm not sure this is what the EC is thinking about -- AlbertoDiMeglio - 27-Feb-2011 |
|||
7 | 10 | 3.1 | Section title: Can vision have a roadmap? Semantically, roadmap relates to a process, and vision in this section is not described as a process. Eurospeak overload -- OxanaSmirnova - 12-Dec-2010 Well, the vision is usually defined as a description of a final status of things that your project aims at establishing. The mission is what you intend to do to get there. Therefore I do not see any contradiction in having a roadmap to a vision ,on the contrary. However, it's really a matter of definitions. Not that Google should be taken as ultimate reference, but just try to search for "vision and roadmap" and you get documents from almost every big software player out there, from IBM to Microsoft and the like -- AlbertoDiMeglio - 27-Feb-2011 |
|||
8 | 10 | 3.1 | Point out that this document (DCI Roadmap) itself is a nice example of beneficial collaboration between the projects: instead of creating 6 roadmaps, they jointly created one. -- OxanaSmirnova - 12-Dec-2010 Added "This document represents an important example of collaboration, where the six projects together have joined forces to create a single vision all of them can contribute to, rather than defining six separate visions" -- AlbertoDiMeglio - 27-Feb-2011 |
|||
9 | 11 | 3.2 | This roadmap does not address the DCI vision in Appendix A. The vision is “A grid of virtualised resources, federated across ERA”. Nothing in this section explains how EMI will facilitate virtualisation and federation. -- OxanaSmirnova - 12-Dec-2010 This is not explained here because it is described in Part 2 as being base on important EMI functionality like messaging, integration of virtualization, chnges in the security models, etc. In addition, the roadmap in Part 1 doesn't describe technical objectives. The yearly technical plans are important milestones in the roadmap and are the place where this kind of information must be described -- AlbertoDiMeglio - 27-Feb-2011 |
|||
10 | 11 | 3.2 | At this point in the document, this vision (DCI) is not defined, makes reading difficult. -- OxanaSmirnova - 12-Dec-2010 I garee, but I did't find a better way of doing this without repeating the same text in both Part 1 and Part 2. I've split the responsibilties of the two parts, putting in part 1 a description of the implementation details and leaving in Part 2 the definition of the vision. This is the drawback of having the document structured in this way, but this is what has been agreed. -- AlbertoDiMeglio - 27-Feb-2011 |
|||
11 | 11 | 3.2 | Line 2: Another semantic problem: roadmaps don’t evolve (not much, anyway), - rather, they describe evolution -- OxanaSmirnova - 12-Dec-2010 |
|||
12 | 11 | 3.2 | Item 2: Elaborate on what is going to be merged, and why does it lead to redundancies and duplications. Explain that the providers bring in products offering similar functionalities, and EMI middleware is a merger of all contributed components. Similarity in functionalities may result in redundancies. Would be nice to refer here to the Technical Development plan, which explicitly identifies components to be phased out, as well as some new components. -- OxanaSmirnova - 12-Dec-2010 |
|||
13 | 11 | 3.2 | Item 2: Semantics again: how can innovation change? You perhaps meant “from new technology trends”? -- OxanaSmirnova - 12-Dec-2010 |
|||
14 | 11 | 3.2 | Item 3: Explain what are Reference Services: is it a core subset of EMI components, or all of them? Explain also how do components that stayed out of EMI (those to the right of the yellow box?) relate to the Reference Services. -- OxanaSmirnova - 12-Dec-2010 |
|||
15 | 13 | 3.2 | Figure 2: Add numbers to the Phases as in the text (from 1 to 5), to improve readability -- OxanaSmirnova - 12-Dec-2010 |
|||
16 | 13 | 3.2 | Item 4: A reference to a document describing the "Works with EMI" progremmae ([R1]?) would be handy -- OxanaSmirnova - 12-Dec-2010 |
|||
17 | 14 | 3.2 | Para 4: Please comment on support plans for EMI 2 and EMI 3: Fig 3 creates an impression they will be supported forever -- OxanaSmirnova - 12-Dec-2010 |
|||
18 | 18 | 4 | For each project, mention explicitly: (a) specific common objectives and (b) specific collaboration mechanisms. Currently this information is well hidden in plain text. -- OxanaSmirnova - 12-Dec-2010 |
|||
19 | 18 | 4.1 | One would expect this section being identical to 4.2.1 in Appendix A, yet they are not quite the same; either syncronisation or explanation of different accents is needed -- OxanaSmirnova - 12-Dec-2010 |
|||
20 | 22 | 5.1 | Item 1: Briefly explain relations between OSG, Globus and VDT -- OxanaSmirnova - 12-Dec-2010 |
|||
21 | 22 | 5.1 | Item 1: This looks more technical than others; but since we talk about VOMS and CREAM, some specific examples of future collaboration are needed. E.g., will VDT keep distributing own VOMS and CREAM packages, or will they take it from EMI? -- OxanaSmirnova - 12-Dec-2010 |
|||
22 | 24 | 6 | Line 3: Experimental in which sense? Conducting common experiments? Please elaborate. -- OxanaSmirnova - 12-Dec-2010 |
|||
23 | 24 | 6 | Para 2: Any hint (already here) on who might that be? What if nobody is interested? -- OxanaSmirnova - 12-Dec-2010 |
|||
24 | 25 | 7 | The text in this section has no actual conclusions; either the section has to be renamed to e.g. “Outlook”, or conclusions should be written. -- OxanaSmirnova - 12-Dec-2010 |
|||
25 | 26 | A | This Appendix A embedded in the deliverable is rather confusing, as its sheer volume is larger than the deliverable itself, and yet it is not subject to EMI QA (and has no table of contents, making it difficult to browse). For better readability, and to stress that this part did not get through our quality assurance process, it may make sense to format it differently (maybe use different, smaller typeset?) Better still, if the 6 projects can put it on the Web and just refer to it via an URL, instead of including in 6 deliverables and making 20 reviewers reviewing the same text. -- OxanaSmirnova - 12-Dec-2010 |
I | Attachment | History | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|---|
![]() |
EMI-DNA1.4-1277542-EMI_Roadmap_DCI_Collaborations-v0.3-OS.doc | r1 | manage | 1548.0 K | 2010-12-12 - 18:00 | OxanaSmirnova | Draft with comments and minor editorial corrections by OS |