I'm on-board with all of this. (I also would be OK delaying 3.0, if
that were the consensus).

There is one issue in here I think we should dive into:

What sort of process were you thinking of for the automation?

Some context, starting from what we all likely already know:

The bulk of the code review and pre-merge testing results are recorded
in gerrit. Once the pre-merge testing passes, a patch is cherry-picked
to the git repo hosted with gerrit. To get the patch to the Impala git
repo hosted by the ASF, bin/push_to_asf.py is run by a human who
supplies his or her ASF credentials. That script copies the commit to
the ASF git repo.

Often, 2-3 commits will pile up in gerrit before some committer runs
that script and pushes them to ASF.

We could edit that script (bin/push_to_asf.py) to help with the cherry
picks, so that each time a commit is made, the committer must say
whether the commit goes in 2.x, 3.0, or both, but the commits are
often made by people who didn't author the patches, so they may not be
sure which branch to go in.

Additionally, gerrit code review is intimately tied to the git repo.
Gerrit runs a git repo under-the-hood, and I believe that the branch
on gerrit's git that changes are cherry-picked to after pre-merge
testing is identical to the Impala git repo hosted by the ASF - down
to the hashes, even. If we think 2.x and 3.0 will diverge enough that
we'll want different code reviews for different branches, then we
might want two different branches on gerrit, too.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB