I believe the newer versions of gerrit support a label-like concept called 'hashtags' (apparently the authors of Gerrit love Instagram). They allow you to tag a review/commit with arbitrary strings. Perhaps this feature could be used so that patch authors can tag their reviews/commits as "stable-candidate" and Jim can easily query for them? Then when it has been cherry-picked to the branch, a "stable-picked" tag can be added to indicate it has been merged?
If this sounds useful, let me know and I can look into enabling the feature on gerrit.cloudera.org. I think some non-trivial config change has to be made, though, so would take a week or two. -Todd On Fri, Aug 19, 2016 at 9:38 AM, Tim Armstrong <[email protected]> wrote: > I think the first sounds easiest. If commit authors really think something > should go in the release they can always reach out to you. > > On Fri, Aug 19, 2016 at 9:15 AM, Jim Apple <[email protected]> wrote: > > > 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. > > >> >> > > >> > > > -- Todd Lipcon Software Engineer, Cloudera
