On Mon, Feb 5, 2018 at 8:50 AM, Sage Weil <sage@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
