COSMOS RE PROPOSAL

In the May 2007 F2F, there was a discussion about the responsibilities of the Release Engineering team. This is a copy of the minutes around that discussion.

Release Engineering Discussion

We had discussed the work items a release engineering team should be responsible for delivering with the goal of identifying the amount of resources required to successfully support the COSMOS development team.

The release engineering work is critical for the success of the project as a whole since we depend on it for making our work available to the end user and for integrating with other projects. Each component lead is responsible for working with the release engineering team to create the set of build scripts, packaging, etc. required to get their code into the driver.

Without a well established build and release process, that ensures the production of high quality software, COSMOS will be unable to graduate to a top level project. Based on Hubert’s experience as a release engineering team lead for TPTP and his current support on the COSMOS project release engineering work, he identified a list of items this team should be responsible for delivering.

The following items are the overall responsibility of the release engineering team. This list is based on the things that were required during the COSMOS iteration process. Many of these steps can be automated based on existing scripts. Some of these steps have not been completed as of yet because of the resource constraints on the project.

1. Manage the build process
   • Monitor the status of builds.
     • Notify developers of broken builds. Note: The COSMOS team needs to establish its process for handling broken builds.
   • Work with the component teams to incorporate build script changes based on new requirements, new features, et.
   • Publish builds to eclipse and/or the update mangaer site.
   • Administer and maintain build machines. This may involve managing user accounts, disk space, security patches, removing unused builds, adding harddrives, etc.
   • Produce and publish build reports, including errors and hygiene reports (see below)
2. Coordinate all the build related work with other Eclipse projects (Orbit, Europa, et. )
   • Make sure the right platform is used for build
   • Use the right common components from Orbit
   • Be the focal point in COSMOS for packaging related problems ( the rel eng team should know if a common component is already available in Orbit, should know what platform level we should run against, what jre level, etc )
   • Attend Europa and Orbit meetings and represent COSMOS
3. Ensure software delivery
   • Establish and maintain software download site
   • Establish and maintain Eclipse update manager support
4. Iteration test support
   • test pass settings ( candidate build, announce new candidate builds, build related announcements, patching the build)
   • test pass reports and test coverage statistics
   • settings machines for testing if special configurations are required
5. Maintain project hygiene
   • Identify code with invalid/missing
   • Identify plugin with missing/incorrect versions
   • Identify internal API usage
   • Ensure the proper license files are included
   • Identify invalid dependencies, e.g. external code libraries not approved by the eclipse IP process
6. Manage Eclipse infrastructure
   • COSMOS committer access management:
     • coordinate with the eclipse system admin to make changes to the CVS access control.
   • Bugzilla management:
     • adding new components and changing default buzilla component owners. (Project lead can delegate the build team to do this task.)
   • CVS administriative tasks:
     • removing/moving files, creating branches, etc.
     • creating new branches and set up the build scripts to build on the new branch for each new release

After these tasks were outlined, the team made the following decisions:

1. The component owners are responsible for working with the build team to ensure their code is included properly in the release engineering process. This includes creating the initial build scripts, et.
2. The build team must be made up of representatives from different companies.
3. The initial team will be made up of Joel and Hubert. CA will begin contributing to this team and the target is for them to be up to speed and in a position to lead this team by the end of June.

In order to get started immediately, the team at the face to face also outlined an initial set of deliverbles and action items for the release engineering team.

1. Identify the build required build infrastructure
   • Investigate the possibility to do the build on an eclipse server. (The build is currently done in IBM. Builds are uploaded to eclipse for public consumption.)
     • create a web dash board/report for viewing build status, build log files, starting builds, etc.
2. Create SDK packages with source plugins generated.
3. Sign jar files for nightly builds
4. Run pack200 on all class files for better compression results.
5. Start generating reports on the build (potential reuse of tools from TPTP project)
   • CVS activity report (commits done between builds)
   • Bugzilla activities between builds (need to define a format for writing CVS commit comments)
   • Report on files that miss copyright statements, wrong copyright years, and files that contain non-EPL copyright statements
   • report on classes that use internal packages of other projects
   • Report on version number of each plugin and compare with the previous release. Indicate which plugins have changed since the previous release and require a change in version number.
   • Generate reports on plugin dependencies, feature structures, etc.
6. Create an update site for the project, write scripts for maintaining/updating the update site.

It is recognized that the release engineering team will need to have a broad set of skills. While not everyone on the team posses these skills immediately, it is expected that they can come up to speed over time. The skills identified to be required for the release engineering team are:

1. Ant scripts, php
2. Eclipse skills ( required to create and update feature content, test Update Manager, branch CVS for new releases, give CVS access, etc )
3. Plugin development knowledge – it may be required to update plugin version numbers in the Manifest.mf, update build.properties file, etc