| Re: [ee4j-pmc] Release Reviews |
Greetings EE4J PMC. My apologies for taking so long to get this out.Regarding releases...Before any project can release, all requests for the review of intellectual property (both project code and third party content) that is included in that release must be resolved by the Eclipse IP Team. By extension, all intellectual property, including the initial contribution and any third party content required by the project code must be presented to the IP Team via CQs. Project teams must present content to the IP Team, and must receive authorization before it is actually incorporated into the project code. Note that ongoing contributions by project committers do not need to be vetted by the IP Team.For their first release, an Eclipse project must engage in a Release Review. All subsequent major (API breaking) and minor (new functionality) must engage in a Release Review. Service releases (bug fixes only) require no formal ceremony.Project teams should create a Release record in the Project Management Interface (PMI) as early as possible in the release cycle. This record should include at least a projected release date and a brief description of the sorts of things that the project team expects to accomplish with that release. This information can change during the release cycle (be sure to communicate changes with the project community).The Release Record serves as the project plan. It should provide the community with insight into the activities that the project team intends to undertake. The planned date for a project release factors into the IP Team resource planning process.Note that creating a Release Record at the last minute does not automatically place your project at the front of the IP Team's queue. Create the record early in the process--especially if you know that a release is months away--if you want it to factor into the IP Team's planning.The purpose of a Release Review is to ensure that project teams are following the process. During the review, the Eclipse Management Organization (EMO) will validate that the IP Policy and Eclipse Development Process are being followed; the basic intent (at least for new projects) is to ensure that project teams are doing the sorts of things that they need to do to be successful open source projects.The PMC has a role in the Release Review process. The EMO expects that the PMC knows the community best and by requiring that the PMC approve of a release and the corresponding review materials, gives the PMC an opportunity to do their own review and ask for their own refinements.We specify Release Reviews by the date that they end. Release Reviews are posted for a minimum of one week to the community for feedback. The date specified in the review is the last day to provide that feedback.We (the EMO) tries very hard to set up reviews to be successful. We try very hard to make sure that issues are discovered and mitigated early in this process so that the final approval on the end date is virtually always successful. In rare cases where we are not able to resolve issues by the end date, we prefer to just defer declaring success until the issues are resolved. I don't recall the last time we actually failed a Release Review.Release Review end dates are scheduled on the first and third Wednesdays of the month. In exceptional cases, we will run extra review, but we try to stick to that cadence.The actual release date must be some period of time after the completion of a successful review. "Some period of time" is not formally defined. Many projects release on the same day their review ends. Most releases are issued within days of the successful review, but some projects go weeks. The EMO will look to the PMC for advice.By way of example, the projects that engage in the Eclipse Simultaneous Release engage in a massive combined release review in mid-May, but actually have their release at the end of June.The actual code for a project should be basically stable and the feature set complete before we engage in a Release Review. Project teams can continue to make changes during and after a Release Review. The nature of the sort of work that's "permitted" between the initiation of the review and the actual release is at the discretion of the PMC. The PMC may, for example, decree that only critical bugs can be fixed during this ramp down.If a release version has content from another Eclipse project as a prerequisite, that content must be a released version.The EMO takes a big picture view regarding the dependencies between Eclipse projects and the release state of the content. When an Eclipse project has another Eclipse project as a prerequisite, the release version of the first project can only include content from a release version of the second project. A project can engage in a Release Review with an intent to use not-yet-released content from another project, as long as that prerequisite content is actually itself released by the release date.Example: Project A uses content from Project B. Both projects are in active development and Project A uses content from Project B that is not yet released. Project A and Project B engage in Release Reviews that resolve successfully on the same date. Project B pushes out their final build; some time after that, Project A pushes out their final build.The EDP requires that reviews be open for community feedback for a minimum of a week. The project team should initiate the review process with the EMO two weeks ahead of the review's end date. The EMO will regard a submission to review a project's IP Log or a request for approval from the PMC as initiating the process (a project may also send a note to emo@xxxxxxxxxxx). The EMO provides guidance through this process once it is initiated.My recommendation is that the PMC pick a single date to engage in Release Reviews for all projects. That date should be far enough in advance of the project release date that we'll have enough time for projects to assemble their final bits together. I'll need the PMC's help to determine what that assembly process looks like and how long it will require.Have I missed anything? Any questions?Wayne--Wayne BeatonDirector of Open Source ProjectsThe Eclipse Foundation