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-...@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
signature.asc
Description: PGP signature
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev