[llvm-dev] [cfe-dev] [Release-testers] RFC: Release process changes

[Fāng-ruì Sòng via llvm-dev]

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 ...

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-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev