Difference between revisions of "Simultaneous Release Roles"

From Eclipsepedia

Jump to: navigation, search
(Simultaneous Release Roles)
(Webmasters)
Line 53: Line 53:
  
 
* Webmasters help by telling how and when to update and how to cause least impact to Eclipse mirroring system.
 
* Webmasters help by telling how and when to update and how to cause least impact to Eclipse mirroring system.
 +
 +
=== Related Activity ===
 +
 +
There are some related activities which, while related, are independent of the roles of the Planning Council and the Simultaneous Release.
 +
 +
==== EPP Packages ====
 +
 +
EPP produces packages of all-in-one downloads to make it easier for users in the community to get started.
 +
 +
While EPP of course uses the contents of the Simultaneous release, their processes, criteria, and packages are their own.
 +
 +
==== Eclipse Foundation Download pages ====
 +
 +
The Eclipse Foundation can provide download pages meant to feature the contents of the simultaneous release, sometimes even, perhaps providing web page wizards, etc, to make it easier for users to get started. Again, while this uses the content of the Simultaneous Release, their process, efforts, goals, etc., are their own and not strictly related to the Planning Council or Simultaneous Release.

Revision as of 01:38, 20 April 2009

Contents

Simultaneous Release Roles

Many tasks and activities must take place to produce our yearly simultaneous releases.

This document is to list some of those tasks and activities and group them according to "roles" that various people play. Of course, the same person may fill more than one role and sometimes a role can be shared by more than one person. The important thing about this listing of roles is to make sure that all areas are covered (i.e., assigned to someone), and if someone is no longer able to perform a role, that someone else can found that can pickup their "job" with a clearer understanding of what's expected.

This document is expected be be updated frequently, both as we learn or think of things we do that have just never been written down, but also because conditions change both within and across releases so the list is by no means static.

Also, please note, at this point in time, this is the first draft of this document so it may contain many errors and omissions. Greatest appreciation to you who find them. The goal of this document is not to invent something new, of what we would wish to have, but just to document what tasks we do or have done before.

Planning Council

  • Creates a schedule for the yearly releases and maintenance releases. Projects of course can have additional releases ... but all participants are expected to deliver and test the the main yearly release, and two subsequent service releases.
  • Determine the code name of the yearly release.

Planning Council Chair

  • Schedule and Lead meetings as required.
  • Make sure the council operates fairly, according dev. process, and at the same time making sure that the yearly releases stay relevant to users, and adopters, and are of the expected quality, etc.
  • Make sure the schedule stays on track, and if not take corrective action.
  • Finds people to solve specific problems, or to fill required roles.
  • Leads the planning council to consensus on the release criteria, name, etc.

Build Producer

  • Historically there's always been an innovator in Eclipse who produces a "build system" that Projects can input to, and when run produces an update site, basically, that allows a common place for all Eclipse Users to find the functionality they are looking for, instead of having to search all over eclipse and find all the bits and pieces that they require.
  • The Build Producer creates and maintains that system, not only for the yearly release but also for the subsequent simultaneous releases. So this is a fairly long term commitment.
  • The Build Producer must also document the system, both in terms of what projects need to do (and not do) but also document well enough that someone could "reproduce" the build on their own hardware, especially for testing purposes.

Build Meister

  • Keeps the builds running smoothly day to day.
  • Makes sure that if someone breaks the build, that they attend to it relatively quickly.
  • Runs scripts to "move" the build from one location to another, such as form build machine to staging area, and then later to releases area.
  • Runs scripts to do any "final" preparation work that's required, such perhaps to run pack200 on all the jars. (This has been required in the past ... some efforts are being made so may not be required for Galileo).


Build Tester

  • Creates scripts to run on a build to be sure various criteria are met, for example, that all jars are signed (and if not, open bugs against those who have not signed their jars).
  • And many more tests that can be automated (e.g. check if execution environment specified, check if different versions of third party bundles used, etc).
  • Run scripts to collect interesting statistics on the release ... how many bites, how many projects, how many downloads.


Webmasters

  • Webmasters help by telling how and when to update and how to cause least impact to Eclipse mirroring system.

Related Activity

There are some related activities which, while related, are independent of the roles of the Planning Council and the Simultaneous Release.

EPP Packages

EPP produces packages of all-in-one downloads to make it easier for users in the community to get started.

While EPP of course uses the contents of the Simultaneous release, their processes, criteria, and packages are their own.

Eclipse Foundation Download pages

The Eclipse Foundation can provide download pages meant to feature the contents of the simultaneous release, sometimes even, perhaps providing web page wizards, etc, to make it easier for users to get started. Again, while this uses the content of the Simultaneous Release, their process, efforts, goals, etc., are their own and not strictly related to the Planning Council or Simultaneous Release.