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