Re: Better anticipation for minor releases

[Ken Dreyer <kdreyer@redhat.com>]

On Mon, Feb 5, 2018 at 8:50 AM, Sage Weil <sage@newdream.net> wrote:
> Building from a tag seems like the wrong approach.  What if the build
> fails for some reason (e.g., minor error in cmake files that affects
> release build but not test build)?

Do you have a specific example of this type of failure?

In general I want our test builds to be as close to our release builds
as possible. Some of the reasons for the differences are mainly
historical rather than technical. If there are particular differences
that could cause build failures, let's identify those and fix them!

> Or, perhaps for important, what if we
> get to the point where we do some testing on the final build
> artifact before finalizing/blessing the release?

This is an interesting idea. How would you picture someone doing this
testing, and who would that person be?

What happens when the testing fails and people have already merged
more racing PRs to luminous? We would have to back those out right?

v10.2.5 and v10.2.9 were quick releases to fix problems in the
immediate prior releases. If we merged a bunch of PRs at the same time
there, those quick versions would not have been as quick/safe.

> I don't understand why racing updates is a problem.  git branching/merge
> solves exactly this problem:

Again just my opinion, I think this makes the history harder to read.
For example, it's already a challenge to remember to run "git
describe" on the merge commit rather than the code change commit.