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 fined them. The Goal is not to invent something new, of what we would wish to have, but just to document what we do and have done before.
See Planning_Council for now.
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.
- 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 the 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 would "reproduce" the build on their own hardware, usually 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.