Jump to: navigation, search

Difference between revisions of "Platform-releng/Galileo"

m
m
Line 9: Line 9:
  
 
== Everyone can build ==
 
== Everyone can build ==
* provide an releng product download that people can download and replicate our build environment. The source build doesn't represent how Eclipse is built.  
+
* Provide an releng product download that people can download and replicate our build environment. The source build doesn't represent how Eclipse is built. Investigate possibilities with JNLP.
* invoke builds from web ui authenticated by eclipse committer rights with parameters - maintenance build vs i-builds, tests or not etc.
+
* Invoke builds from web ui authenticated by eclipse committer rights with parameters - maintenance build vs i-builds, tests or not etc.
 +
* Expose all our infrastructure to open source
 +
* Modularize our scripts - compiling, package, test (JUnit correctness, performance, Releng validation, API Tooling, version compare, code coverage).  This will also allow shorter test build runs.
  
 +
==Stable future==
 +
* Implement code coverage tools [https://bugs.eclipse.org/bugs/show_bug.cgi?id=241254 Bug 241254]
 +
* Mentor a new release engineer
 +
* Implement prebuild validators
 +
* Evaluate common failures determine how they can be mitigated.  Rewrite if necessary.
  
 
== Further leverage p2 and enhancements to PDE build ==
 
== Further leverage p2 and enhancements to PDE build ==
Line 19: Line 26:
 
<h4>Blue sky ideas</h4>
 
<h4>Blue sky ideas</h4>
 
* incremental build from p2 repository
 
* incremental build from p2 repository
* compile at foundation, package locally, depends on availability of the eight vms we use
+
* compile and sign at foundation, package locally, depends on availability of the eight vms we use
 
* Evaluate if platforms, or zips can be removed from the build, with scripts to build with p2
 
* Evaluate if platforms, or zips can be removed from the build, with scripts to build with p2
* Stability - evaluate common failures in build and determine how they can be improved.
 

Revision as of 15:28, 12 September 2008

Platform Release Engineering Galileo Plan

This document is a work in progress of the major changes that we would like to make during the Galileo release cycle.

Built for speed, faster tests we need

  • Run build with 1.6 vm Bug 237354
  • Run tests in parallel on several machines to reduce testing time
  • Generic templates for complex build changes such as adding a new port and packaging.

Everyone can build

  • Provide an releng product download that people can download and replicate our build environment. The source build doesn't represent how Eclipse is built. Investigate possibilities with JNLP.
  • Invoke builds from web ui authenticated by eclipse committer rights with parameters - maintenance build vs i-builds, tests or not etc.
  • Expose all our infrastructure to open source
  • Modularize our scripts - compiling, package, test (JUnit correctness, performance, Releng validation, API Tooling, version compare, code coverage). This will also allow shorter test build runs.

Stable future

  • Implement code coverage tools Bug 241254
  • Mentor a new release engineer
  • Implement prebuild validators
  • Evaluate common failures determine how they can be mitigated. Rewrite if necessary.

Further leverage p2 and enhancements to PDE build


Blue sky ideas

  • incremental build from p2 repository
  • compile and sign at foundation, package locally, depends on availability of the eight vms we use
  • Evaluate if platforms, or zips can be removed from the build, with scripts to build with p2