Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS RE AND BUILD WISH LIST"

(What we need)
Line 12: Line 12:
 
<ol>
 
<ol>
 
<li>COSMOS needs have a continuous and well-defined build process -- Jimmy Mohsin<br/>
 
<li>COSMOS needs have a continuous and well-defined build process -- Jimmy Mohsin<br/>
# Have a well-organized download page that is updated with a FUNCTIONAL build at least by the middle of each iteration (if not earlier).  
+
<ol><li>Have a well-organized download page that is updated with a FUNCTIONAL build at least by the middle of each iteration (if not earlier).  
  
 
<font color="blue">
 
<font color="blue">
 
<mdw>I would advocate FUNCTIONAL build be available every week during an iteration.  It should be considered a p1 on the project if we do not have this.  I'd be willing to update the cosmos dev process as well.</mdw>
 
<mdw>I would advocate FUNCTIONAL build be available every week during an iteration.  It should be considered a p1 on the project if we do not have this.  I'd be willing to update the cosmos dev process as well.</mdw>
 
</font>
 
</font>
 
# The download page must have a build that has ALL the components as soon as they become available.  Even though this seems obvious, I state this explicitly since in the past, some components did not make it into the build even though they were available.
 
# The “new” build process will enable non-development teams, e.g. QA to pick-up a build DURING and (obviously) till the end of an iteration.  This will enable the QA team NOT to have to wait till the end of an iteration for testing.  E.g. QA could initiate the unit level testing BEFORE iteration end.
 
# With a continuous build process, we would be better positioned to address the iteration close build fire drills….
 
 
</li>
 
</li>
 
+
<li>The download page must have a build that has ALL the components as soon as they become available.  Even though this seems obvious, I state this explicitly since in the past, some components did not make it into the build even though they were available.</li>
 
+
<li>The “new” build process will enable non-development teams, e.g. QA to pick-up a build DURING and (obviously) till the end of an iteration.  This will enable the QA team NOT to have to wait till the end of an iteration for testing.  E.g. QA could initiate the unit level testing BEFORE iteration end.</li>
 +
<li>With a continuous build process, we would be better positioned to address the iteration close build fire drills…. </li></ol>
 +
</li>
 
<li>COSMOS needs to be packaged according to adoption scenarios:<br/>
 
<li>COSMOS needs to be packaged according to adoption scenarios:<br/>
  
Line 37: Line 35:
 
</mdw>
 
</mdw>
 
</font>
 
</font>
 
 
  
 
<li>The build needs to detect stop-ship problems and send out notifications:</li>
 
<li>The build needs to detect stop-ship problems and send out notifications:</li>

Revision as of 17:08, 17 January 2008

COSMOS > COSMOS RE AND BUILD

Release Engineering and Build Wish List

<mdw> Since we are opening up enhancement requests, we should tie these back to use cases per our development process. I think many of these, e.g. the download site, would support the idea of the CMDBf toolkit, as an example. </mdw>

What we need

  1. COSMOS needs have a continuous and well-defined build process -- Jimmy Mohsin
    1. Have a well-organized download page that is updated with a FUNCTIONAL build at least by the middle of each iteration (if not earlier). <mdw>I would advocate FUNCTIONAL build be available every week during an iteration. It should be considered a p1 on the project if we do not have this. I'd be willing to update the cosmos dev process as well.</mdw>
    2. The download page must have a build that has ALL the components as soon as they become available. Even though this seems obvious, I state this explicitly since in the past, some components did not make it into the build even though they were available.
    3. The “new” build process will enable non-development teams, e.g. QA to pick-up a build DURING and (obviously) till the end of an iteration. This will enable the QA team NOT to have to wait till the end of an iteration for testing. E.g. QA could initiate the unit level testing BEFORE iteration end.
    4. With a continuous build process, we would be better positioned to address the iteration close build fire drills….
  2. COSMOS needs to be packaged according to adoption scenarios:
    Read first thoughts on how to package COSMOS drivers
  3. Bugs opened for the Build component

    <mdw> This includes the creation of an update manager site for downloading the eclipse plug-ins that we provide. We would start with:

    • SML Tooling
    • WSDM Tooling

    </mdw>

  4. The build needs to detect stop-ship problems and send out notifications:
    • Breaking API
    • Legal issues:
      • Missing copyrights
      • Out-of-date copyrights
      • Missing about.html files

    <mdw> Like the BVT results, these should be made available via the web site as part of the daily builds. </mdw>

    • Dependencies not broken when new code added
  5. Build Verification Test (BVT) run and results posted for everyone to see
  6. We need agreement on what exactly the RE team is responsible for. FYI TPTP used this list of responsibilities: http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg03024.html


<mdw> Not sure where this fits, but we need to make sure we are running the build on the eclipse server and that we properly manage the space. A number of times we've received e-mails about exceeding our disk space quota. </mdw>

What we have today

COSMOS Release Engineering and Build

What will it take to get what we need

  1. Before the build can act on this item, the following must happen:
    1. Defining the use cases separated by roles (so that we know who needs what).
      1. Need roles for the Data Collection component.
      2. Need roles for the Data Visualization component.
      3. Read first attempt to define these roles for the Resource Modeling component.
    2. The code must be refactored so that the build can package the code the way that we think that a consumer intends to use it.
      1. Need to refactor the code for the Data Collection component as per its roles TBD above.
      2. Need to refactor the code for the Data Visualization component as per its roles TBD above.
      3. Resource Modeling bugzillas for refactoring:
    3. Fix other bugzillas for refactoring:
  2. Fix existing bugzillas owned by the build team
  3. Involve the build team in helping with feature definition to enable an UpdateManager install.

Back to the top