Requirements For Participation

Milestones and Release Candidates

The milestone dates are at roughly 6 week intervals. Any end-of-cycle release-candidate (RC) dates are typically one week apart. Each project has their deliveries due at times offset from the end-date, so that the project dependencies can come together in a reasonable order. These delivery times are based on the dependencies between projects -- they are called the +0, +1, +2, and +3 dependencies. Projects themselves decide if they are +0, +1, +2, or +3. The actual time-offset represented by these intervals change over the course of the year of development, being several days at first, but then only one day near the end of the release. The following calendar is the official schedule of the overall Helios Release. Projects are free to have their own schedules as long as they meet the Helios deliverables.

Note that projects choose their +n category based on major or primary dependencies. There are many cases a project might have to deliver pieces of their code a little earlier, if some project depends on it. These sorts of deviations are left the the projects to work out among themselves.

Communication

Cross-Project Milestone & RC Status Reporting

It is essential for many aspect of the simultaneous release that communication be prompt and clear, on many topics. One of the most important ones, is if someone is not meeting some date or delivery. Put another way, we assume everyone is on target and has delivered their stuff unless a note is sent to cross-project list that you are delayed.

Conference Calls

The Planning Council is the body responsible for coordinating the Helios release train. Thus, its conference calls are the Helios planning and coordination calls.

Mailing Lists and Newsgroups

Eclipse projects have three communication channels: a mailing list for developers, a newsgroup for users, and Bugzilla. While Helios is not a "project" per se, it will use the same structure:

Developer mailing list

cross-projects-issues-dev - mailing list for developers and releng (see archives). This is the list to use to discuss build issues, announce changes in plans, slippage in deliverables, etc.

Users news group

Bugzilla

If any doubt about where a bug belongs, it can always start in the "Cross-Project" component. (Under Eclipse Foundation > Community). If it really is a single-project's responsibility, it can be moved to that project. If it is a true cross-project bug, where several projects need to act, then it can stay in the cross-project component.

The Planning Council List

Because there has been confusion in the past, we'll be explicit here that the planning council mailing list (eclipse.org-planning-council) if for Planning Council business, not the Helios Release activities per se. While they sometimes overlap, there is no need to cross post. While anyone can request a subscription to the planning council list (for openness and transparency) the expectation is that only Planning Council members post to it.

Helios Builds and P2 repository

A number of utilities have been written to automate the assembly of Callisto '06, Europa '07, Ganymede '08 and now Helios '09 builds. These are available in their own CVS respository. You can find more information about how this is organized and individual project responsibilities for the build on this Helios Build page (with old information on the Ganymede Build and Europa Build pages).

Coordinated Service Releases

SR1

In the SR1 rampdown, as shown in the following table, there will be 4 RCs, each spanning one week, with projects staging themselves into the build just one day apart.

Projects may elect not to participate in a particular RC, but have an obligation to fix any build problems that is related to their code or p2 repository.

RC1 will be in the middle of August, several weeks earlier than previous years, just to make sure we can still build, etc. Subsequent RCs dates are similar to previous years, except a "quiet" final week is also planned. (It is normally pretty quiet anyway ... this just formalizes it).

The Final week before GA will not have any further builds or contributions, but instead be reserved for final adopter testing and preparation and only emergency fixes for very serious regressions will be considered.

The 'promote' day (9/24) will be the day projects put final zips in their final spot (without displaying them) so they can propagate through the mirroring system. Similar for the p2 repository -- it will be replaced on 9/24 with the new content so it can start mirroring. Note: there is no plan to retain multiple versions in the common discovery repository (unless someone volunteers to do what's required to make that happen). At noon on 9/25 projects can make their final maintenance releases visible.

+0 Mon.

+1 Tues.

+2 Wed.

+3 Thur.

EPP Fri.

RC1

8/10

8/11

8/12

8/13

8/14

RC2

8/31

9/1

9/2

9/3

9/4

RC3

9/7

9/8

9/9

9/10

9/11

RC4

9/14

9/15

9/16

9/17

9/18

Helios SR1 ("GA")

promote: 9/24

GA: 9/25

SR2

2/26/10 (last Friday of February)

Rampdown similar to SR1.

+0 Mon.

+1 Tues.

+2 Wed.

+3 Thur.

EPP Fri.

RC1

1/18

1/19

1/20

1/21

1/22

RC2

2/1

2/2

2/3

2/4

2/5

RC3

2/8

2/9

2/10

2/11

2/12

RC4

2/15

2/16

2/17

2/18

2/19

Helios SR2 ("GA")

promote: 2/25

GA: 2/26

Projects

The projects that plan to participate in the Helios Simultaneous Release are listed below, along with their milestone offsets, leaders, release engineer, and ramp down policy.