> Should we start tagging all candidates with a common label, e.g.

I agree with Lars's suggestion for tagging JIRAs with include-in-v3. I've
done so, and the relevant query is

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

I think amending push_to_asf.py, as you suggest, is a great idea. I think
we have a string ("not for 2.x") which can be used in commit messages to
discourage the cherrypick for the changes we want to be exclusive until we
want to change the defaults in the other direction. (I.e., right now the
string is "not for 2.x", but at some point the string may be "should be
cherrypicked to 2.x".)

I do think that we want to create a gerrit branch to allow 2.x-only changes
to be reviewed in the straight-forward fashion.

-- Philip

On Thu, Jan 11, 2018 at 9:31 AM, Jim Apple <[EMAIL PROTECTED]> wrote:

> 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.