I hadn't decided yet. What do you think? I could test the release, then look for bug fixes that landed in master after my branch started that fix anything that doesn't pass.
Or I could reach out to commit authors and ask them, or I could ask them to email me, like you mentioned. Or I could read commit messages and cherry-pick anything that is a bug fix. On Fri, Aug 19, 2016 at 9:01 AM, Tim Armstrong <[email protected]> wrote: > How do you plan to choose which commits to cherry-pick? Should we let you > know if we think a patch should/shouldn't be part of the release? > > On Fri, Aug 19, 2016 at 8:44 AM, Tom White <[email protected]> wrote: > >> Thanks for volunteering to do the release Jim! The plan looks fine to me. >> >> Tom >> >> On Fri, Aug 19, 2016 at 4:42 PM, Todd Lipcon <[email protected]> wrote: >> > Sounds great to me! >> > >> > Todd >> > >> > On Aug 19, 2016 8:41 AM, "Jim Apple" <[email protected]> wrote: >> > >> >> I would like to volunteer to be the next release manager for an >> >> upcoming Apache Impala 2.7 (incubating) release. I plan to: >> >> >> >> 1. Get a vote done adding to our bylaws the procedure for creating a >> >> branch. (See thread from yesterday) >> >> >> >> 2. Create a release branch, possibly backdated a few commits from HEAD >> >> to a commit that looks stable. >> >> >> >> 3. Maintain that branch by cherry-picking bugfix commits from "master" >> >> as necessary to get the tests running cleanly. >> >> >> >> 4. Make a release candidate and call for a vote here, then on the IPMC >> >> list (which is required for Incubator releases) >> >> >> >> Obviously, this glosses over some details about publishing and signing >> >> releases, but I would welcome feedback on this outline. >> >> >>
