On 05/21/2020 05:38 PM, Fāng-ruì Sòng wrote: > On 2020-05-21, Michał Górny via cfe-dev wrote: >> 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. > > Just to confirm: are bug-fix releases X.Y.1 X.Y.2 X.Y.3 ... >
Yes, this is correct. -Tom > Seems reasonable. Package maintainers on various distributions may > have more words here. > It seems that we have a +1 from Gentoo now. > > >>> >>> ** 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 >> > > > >> _______________________________________________ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev