Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> To:
project issues <cross-project-issues-dev@xxxxxxxxxxx> Date:
Confusion regarding the timing (and nature)
of Release Reviews and Releases Sent
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
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
Wayne -- Wayne Beaton Director of Open Source Projects The Eclipse Foundation_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev