Eclipse project teams: this post is for you.
It’s time for Eclipse Projects to start announcing their participation in the Eclipse Luna 2014 Simultaneous Release.
All aboard the Release Train
I’ve changed the way things work with regard to keeping track of who is participating in the simultaneous release. Previously, a project representative just had to flip a bit in the project metadata; now, projects must announce their participation on the cross-project-issues-dev mailing list. I’m keeping track of this information on the Luna release tracking page.
This change in process has several advantages:
First, a project needs to have at least on representative as a member of the list to announce. This seems pretty obvious, but there have been multiple examples in the past of projects that were unaware of important messages and discussion because they didn’t have this representation. Communication is a key aspect of participation in the simultaneous release, and the cross-project-issues-dev mailing list is where the cross-project communication occurs.
Second, announcing on the list provides better transparency and openness. The community will have a much better chance of understanding what each participating project is doing and have a much more obvious opportunity to ask questions and otherwise participate.
Third, it’ll be harder for projects to “sneak in” after the fact. Believe it or not, there are multiple examples of projects who have “flipped the bit” on participation with older (past) releases.
I’m always concerned about adding more work/process for projects. But I don’t think that this we’re adding anything new here. According to the Eclipse Development Process, a project is required to complete a plan, register a release record, and engage in a release review for every major and minor release anyway. Projects that participate in the simultaneous release are required to participate in the cross project communication. I believe that this change in process is really just making formal something that projects have done informally in the past.
Projects that intend to participate in Luna, a representative for each project must do the following:
- If you have not already done so, create a release record for the release that’s being contributing to Luna;
- Enter at least plan information for the release, minimally including a description and milestones;
- If you have not already done so, sign up for the cross-project-issues-dev mailing list; and
- Send a note to cross-project-issues-dev with the name of your project, number of the release to include with Luna, and the offset (+0, +1, +2, …).
Generally, the project release associated with the simultaneous release occurs on the same day as the release (June 25/2014). This is, however, not a hard requirement, and it is common for a project to include an earlier (or existing) release. A project that is contributing an earlier release is still required to announce and to participate in cross project communication.
The release’s description should minimally describe the main focus of the release. It should be a relative high-level single-paragraph description of the release itself, not a description of the release review document. The Project Management Infrastructure (PMI) has a facility for providing theme items in a plan; consider using these to provide more detail about key points of focus in the release.
Projects can continue to use the old and painful XML format to specify their plans. Projects that choose to this should still include a high-level single-paragraph description in the release record; I intend to use this information to help drive eyeballs to the projects, and it will be very valuable when the marketing team comes to ask what’s hot and exciting in the release!
