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

[Brooks Davis via lldb-dev]

On Tue, May 26, 2020 at 08:19:57PM -0700, Tom Stellard via lldb-dev wrote:
> On 05/25/2020 05:48 AM, Hans Wennborg wrote:
> > On Thu, May 21, 2020 at 8:59 PM Tom Stellard via Openmp-dev
> > <openmp-dev at lists.llvm.org> 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.
> > 
> > +1
> > 
> > Maybe even stronger than "is allowed to commit", I think we should
> > really think about it as the release manager owning the branch, and
> > has full authority over what goes into it or not. Consulting code
> > owners often makes sense of course, but for many patches, consulting
> > the code owner (when there is one) is an unnecessary slowdown.
> > 
> >> ** 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.
> > 
> > My first thought is that doing all these releases sounds like a lot of
> > work. Would you be doing all of them, or would there be some other
> > arrangement? I suppose if we release this often, and also skip the
> > RCs, we might become more efficient at it :-)
> > 
> 
> Yes, I would plan to do all the releases.  For 9.0.1, there were
> 3 RCs, so 4 releases in total.  Doing 6 instead of 4 is not that much
> more work in my opinion.  Also, we may end up skipping releases if
> there aren't any new changes in the branch.  But doing extra
> releases would be good motivation to try to automates more parts of the
> release process.
> 
> If we do feel like 6 is too many we could lengthen the interval to 3 weeks,
> which would give us just 4 releases.
> 
> > Secondly, is having this many releases useful for downstream? One
> > concern might be that downstream consumers just wait for the .6 one,
> > and then there's no benefit and also no extra testing of the branch.
> > Is it mainly increasing test coverage of the branch that's the
> > motivation, or is it the demand for more bug-fix releases?
> > 
> 
> From me as a distro package maintainer, I'm more likely to package
> a final release than a bug-fix release.  Especially if I know there won't
> be another release candidate or final release coming very soon after.

As the FreeBSD package maintainer, a regular cadence of releases without
RCs seems fine with sufficient CI.  Personally, every 3 weeks makes
me happier than every 2.  It's not a lot of work to do updates (I've
automated most of the bits that aren't dealing with removing patches
that have sense been merged), but users get grumpy if I update the
package too often (lots of FreeBSD users build their own packages on
surprisingly under-powered systems.)

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200603/1d06fc56/attachment.sig>