<div dir="ltr">This set of changes sounds good to me. Thanks!<div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020 at 12:00 PM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I would like to propose a few changes to the LLVM release process.  The<br>
current process is documented here:  <a href="https://llvm.org/docs/HowToReleaseLLVM.html" rel="noreferrer" target="_blank">https://llvm.org/docs/HowToReleaseLLVM.html</a><br>
<br>
There are two parts to this proposal.  The first is a list of clarifications,<br>
which are things we are currently doing that aren't documented. The second<br>
is a list of changes which would actually modify how releases are currently<br>
managed.<br>
<br>
<br>
<br>
*** Proposed Clarifications ***<br>
<br>
<br>
<br>
**  Release manager is allowed to commit changes to the release branch without<br>
    code owner approval.  However, the release manager is encouraged to consult<br>
    with code owners or patch reviewers for non-trivial changes.<br>
<br>
It's not practical to get code owner approval every time.  Either because there<br>
is no code owner or because the number of backports is too high (e.g. pre-rc1 / pre-rc2).<br>
This proposed clarification matches how releases are currently managed.<br>
<br>
<br>
** There is no official release criteria.<br>
<br>
We have time-based releases and when the release is 'ready' has been<br>
up to the discretion of the release manager.  Changing the release<br>
criteria is out of the scope of this proposal, but I do think it would<br>
be good to have a discussion about this as a community, so I'm going to<br>
start a separate thread to discuss this.<br>
<br>
<br>
<br>
*** Proposed Changes ***<br>
<br>
<br>
<br>
** Create a time-based bug-fix release schedule.  After each major release, make<br>
   a new bug-fix release every 2 weeks for 12 weeks (6 releases total).<br>
<br>
** Eliminate release candidates for bug-fix releases.<br>
<br>
The current unofficial bug-fix release schedule is:<br>
<br>
X.Y.1-rc1 (6 weeks after major release)<br>
X.Y.1-rc2 (10 weeks after major release)<br>
X.Y.1-final (12 weeks after major release)<br>
<br>
I think this change will improve the overall test coverage of the release branch.<br>
I don't think the branch itself or even the release candidates get the same<br>
level of testing as the final releases.  If we are consistently snapshotting<br>
the release branch and putting out releases, I think this will make it easier<br>
and thus more likely that users will test out the release branch code.<br>
<br>
Additionally, with more frequent bug-fix release it removes the need to have<br>
release candidate releases. Every bug-fix release (up until the last one)<br>
would serve the same purpose as our current release candidates in that they<br>
are intended to give users an easier way to test the code before the final<br>
release.<br>
<br>
<br>
** Create clear rules for what kind of backports are accepted during each<br>
   release phase.<br>
<br>
* Before RC1:Patches should be limited to bug fixes, important optimization<br>
  improvements, or completion of features that were started before the branch<br>
  was created.  As with all phases, release managers and code owners can reject<br>
  patches that are deemed too invasive.<br>
<br>
* Before RC2: Patches should be limited to bug fixes or backend specific<br>
  improvements that are determined to be very safe.<br>
<br>
* Before RC3/Final: Major Release* Patches should be limited to critical<br>
  bugs or regressions.<br>
<br>
* Bug fix releases: Patches should be limited to bug fixes or very safe<br>
  and critical performance improvements.  Patches must maintain both API and<br>
  ABI compatibility with the previous major release.<br>
<br>
* Final bug fix release: Patches should be limited to critical bug fixes only.<br>
<br>
<br>
<br>
What does everyone thing about these changes?<br>
<br>
<br>
-Tom<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>