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

[Michał Górny via llvm-dev]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200521/fca15c58/attachment.sig>