[cross-project-issues-dev] Confusion regarding the timing (and nature) of Release Reviews and Releases

[Wayne Beaton]

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
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=496321> 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
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=534828> which includes an
effort to more precisely define "Release". We're tracking all of our plans
to update the EDP via Bug 484593
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=484593>. Input is welcome.

Let me know if you have any questions or concerns.

Wayne

[Daniel Megert]

Hi Wayne

A very good summary of the current process!

Dani



From: Wayne Beaton <***@eclipse-foundation.org>
To: Cross project issues <cross-project-issues-***@eclipse.org>
Date: 06.09.2018 21:24
Subject: [cross-project-issues-dev] Confusion regarding the timing
(and nature) of Release Reviews and Releases
Sent by: cross-project-issues-dev-***@eclipse.org



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