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