[Openmp-dev] [llvm-dev] RFC: Release process changes

[Tom Stellard via Openmp-dev]

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