On Mon, 5 Feb 2018, Andrew Schoen wrote: > >> > >> Thought: > >> - Tag or branch a candidate commit for going INTO the QE phase, say > >> v12.2.3-rcX. > >> - Run QE on that tag. > >> - If QE passes entirely, create final tag at same commit as rc tag. > > > > > > That assumes it's possible the release tooling supports releasing something > > other than the tip of a branch (i.e. a SHA1 or tag), though, right? > > I'm pretty sure we have support to build from a tag. The build system > might need a few tweaks, but I think it'd be doable and worth the > effort. 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)? 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? I don't understand why racing updates is a problem. git branching/merge solves exactly this problem: . . o foo o bar ... luminous branch target at time we start build |\ | o baz (a racing change to luminous branch) | | o | v12.2.3 commit bumping release, with signed tag \| o merge commit (luminous branch after release is published) . . If there is something wrong with the branch commit to matching the commit to be built, then *that* seems like the thing to fix in the toolchain (e.g., check branch once at the start, get sha1, then build *that*.) sage -- 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
