On 05/21/2020 05:54 PM, John McCall wrote: > 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? >
There are usually less backports for compiler-rt, so that hasn't been an issue for me, but I do agree that LLVM itself could use more code owners. -Tom > 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
