Simultaneous Release Roles
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.
- 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.
- Establish, by consensual agreement, the criteria required to be part of the yearly release. For example, see Requirements For Participation.
- Determine the code name of the yearly release.
- Also see Planning_Council.
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.
- 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.
- 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).
- 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 help by telling how and when to update and how to cause least impact to Eclipse mirroring system.