<div dir="auto"><div>These changes and clarifications make sense to me.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 May 2020, 12:00 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:0 0 0 .8ex;border-left:1px #ccc solid;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 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" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>