With the change in cadence of the simultaneous release and the resulting shorter 13 week development cycle, I decided to move the Release Review to the very end to maximize the amount of time available for actual development activities. This has caused some confusion with regard to the timing requirements that I didn't anticipate: if you can't release until after you've engaged in a successful release review, how do you get your bits in to the aggregate repository in time for the release which occurs on the same day?
The short answer is that you can (and should)
stage your final bits as necessary before the release date, you just can't call them a release or advertise them broadly in any "official" way (e.g. don't label them as final release bits in your downloads).
Many projects will stage their release bits as their final release candidate before rebranding as GA/release (note that this does not imply any particular technical naming requirements).
My only real concern regarding the very late timing of a Release Review is that it leaves us no time for remediation. I've been running IP scans against the shared repository periodically to ensure that we don't have any exposures there. I just completed a scan and I am confident that all of the content there has been correctly taken through the IP Due Diligence process. Assuming that the PMCs approve the releases and corresponding review materials, we should be in good shape.
While I have your attention, the Eclipse Architecture Council is in the process of making a change to how we do Reviews. The
current thinking is that we will decouple Releases from Reviews and instead require a regular (probably annual) equivalent to the Release Review.
This is actually not as big a departure from the current process as you might think. The EDP describes the Release Review as an opportunity "to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the principles and purposes of Eclipse." i.e. it is far less about the current release than it is about ensuring that the process is being followed and that the project is doing the right sorts of things to attract and grow community.
Likewise, the purpose of an IP Log is not to accurately represent the contents of any particular release, but rather to provide a checkpoint to ensure that the project is correctly following the IP Due Diligence process (so you can continue to receive contributions or engage in other activities that might change the IP Log between the point in time when it is reviewed and approved, and your project makes a release). Note that committers are required to observe the IP Policy and IP Due Diligence Process at all times, so we should always be in correct state with regard to intellectual property management.
For those of you who have made it this far, it would be great if you could weigh in on
Bug 534828 which includes an effort to more precisely define "Release". We're tracking all of our plans to update the EDP via
Bug 484593. Input is welcome.
Let me know if you have any questions or concerns.
Wayne
--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
