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: > Both master and 2.x would be active, and, at least for the beginning, > changes would automatically be pulled into the 2.x line, unless explicitly > blacklisted. 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.
