Given our recent history of releases, I suspect we should revisit this
approach. The fewer steps a release manager has to do (esp those
things we can spread across committers) the more likely we are to
continue to find volunteers who'll get things out at a regular
cadence.
On Thu, May 18, 2017 at
I didn't think that the only way to get something into a release was to
backport it immediately. When I was RM, I would look through the new
commits on master and backport what I thought was safe. That step is in the
release documentation (step 7
(Repeating my comments from the comment on the 1.8.2 release jira):
Master is targetting 1.9.0 now, if the committer of the fix doesn't
cherry pick back to branch 1.8 or branch 1.7 before closing then those
things won't get into new 1.8 or 1.7 releases.
branch-1.8 broke off of master in December
Hi,
Just now I ran into an obscure problem in the 1.8.2 release I thought I had
already fixed.
Researching the issue I found that some of the fixes that have been
committed to the master over the last few months have not been included in
this release.
I myself made some of those fixes and I
