[llvm-dev] 4.0.1 Release Schedule + Need feedback for improving stable releases

[Hans Wennborg via llvm-dev]

On Mon, Mar 27, 2017 at 5:58 PM, Tom Stellard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I would like to start a discussion about improvements to the
> stable release process, but first, here is a proposed schedule
> for the 4.0.1 release.
>
> May 1, 2017 -rc1
> May 22, 2017 Deadline for submitting merge request
> May 29, 2017 Deadline for merging changes.
> June 3, 2017 -rc2
> June 10, 2017 Final Release
>
> This is slightly different from previous stable releases in that
> we are doing an early -rc1 release.  This matches what we do for
> major releases, and I think it will help us get more feedback from
> testers sooner.

Sounds good to me.

> There is now a script in utils/release, called merge-request.sh, which
> you can use to submit merge requests to bugzilla.  It's recommend
> that you use this script in order to give us consistent bugzilla entries.
> However, you can still file bugzilla requests manually if for some
> reason you are unable to use the script.
>
> If you file bugs manually, make sure you mark it as a blocker for
> the release metabug: 32061 and add a link the commit on phabricator
> in the url field: e.g http://reviews.llvm.org/rL12345
>
> Description for the bug should be in the form of:
>
> Merge r123456 into the 4.0 branch : <80 character commit message summary>
>
>
> * Stable Release Improvements *
>
> I would like to start an informal discussion about stable release
> improvements.  My goals for this discussion are to find ways to
> get more community members/organizations using the official stable
> releases, and also to help simplify the release process for users,
> testers, and release managers.
>
> * Ideas:
>
> 1. Longer support for stable release. We currently have 2 major and 2
> stable releases per year.  Each major release is effectively supported
> for only 3 months, because after the x.y.1 release , we move on to the
> next major version.  Our current release schedule is approximately:
>
> March: x.y.0
> June x.y.1
> Sept: (x+1).y.0
> Dec: (x+1).y.1
>
> One idea is to move to 6 releases per year and have an additional
> x.y.2 release after (x+1).y.0, but before (x+1).y.0.  This would
> mean that stable releases are supported for ~ 8 months. So something
> like:
>
> Jan:   (x-1).y.1
> March: x.y.0
> May:   (x-1).y.2
> July:  x.y.1
> Sept:  (x+1).y.0
> Nov:   x.y.2
>
> What do people think about this or other alternative release schedules?
> Would this kind of extended support make stable releases more
> attractive to users/organizations that use LLVM.
>
> My main concern with adding an extra release is placing an extra
> burden on release testers.  For release testers is doing two
> more releases per year practical?

I'd be fine with it. I don't find the release testing itself to be
particularly burdensome. The hard part of releases is chasing down and
fixing bugs, but for .2 releases I expect the process to be pretty
smooth, basically building and testing  a build with a few extra
patches on top of .1.

> 2. Automated release testing.  This is connected to the previous
> idea.  Can we automate the release testing?  It would be great if
> we had some release tester bots that would test the release
> candidates and upload the binaries.  It seems like this should
> be doable within the current buildbot infrastructure.  Is the
> only thing that keeps us from doing this, lack of dedicated test
> hardware?

I think it's more a problem of finding someone to configure and
maintain the bots.

> 3. Automated merge requests.  I would like to come up with a way
> that we can tag commit messages so that a post-commit hook would
> be able to automatically create merge requests in bugzilla.
> There are a few ways I can think of to tag the messages, but I'm
> just going to propose that adding the following line:
>
> STABLE: 4.0
>
> To commit messages would make it a candidate for an automated
> merge request.  Any thoughts?

I'm not sure this is worth it. Aren't many of the "we should merge
this to stable" decisions made after the commit lands?

A commit hook I'd really like is something that updates the bugzilla
when a commit message mentions a PR. That's a different story though
:-)

Cheers,
Hans