On Thu, 2020-05-21 at 11:59 -0700, Tom Stellard via Release-testers 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. > > > ** 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? >
Sounds reasonable to me. I think it would certainly benefit users not to have wait so long for x.1 fixes, and it would mean downstreams have to backport less. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
