Sure. I just uploaded and published a batch of patches: remote: New Changes:
remote: http://gerrit.cloudera.org:8080/12798 IMPALA-6642 (Part 2): clean up start-impala-cluster.py [DRAFT] remote: http://gerrit.cloudera.org:8080/12799 IMPALA-6988: Implement ALTER TABLE/VIEW SET OWNER [DRAFT] remote: http://gerrit.cloudera.org:8080/12800 IMPALA-6223: Gracefully handle malformed 'with' queries in impala-shell [DRAFT] remote: http://gerrit.cloudera.org:8080/12801 IMPALA-6031: Fix executor node count in distributed plans [DRAFT] remote: http://gerrit.cloudera.org:8080/12802 IMPALA-3956: [DOCS] Escape variables with '\' in impala-shell [DRAFT] remote: http://gerrit.cloudera.org:8080/12803 IMPALA-6918: [DOCS] COMMENT ON COLUMN privileges [DRAFT] remote: http://gerrit.cloudera.org:8080/12804 [DOCS] Removed an unused keydef [DRAFT] remote: http://gerrit.cloudera.org:8080/12805 [DOCS] A typo fixed in impala_shell_running_commands [DRAFT] remote: http://gerrit.cloudera.org:8080/12806 Fix zsh issue in set-pythonpath.sh [DRAFT] remote: http://gerrit.cloudera.org:8080/12807 IMPALA-7254: Inconsistent decimal behavior for IN/BETWEEN predicate [DRAFT] Note that I've ignored c01efd096 in master branch since it's reverted later (df78eaec0). In all the above patches, just the last one (IMPALA-7254) needs some changes to fix test failures. I've added what I changed in the review comments. Hope anyone has time can help to review them. Thanks, Quanlong On Tue, Mar 19, 2019 at 4:22 AM Lars Volker <[email protected]> wrote: > Yes, you could have a local branch, cherry pick all the changes that you > know are working plus the last one that causes issues. Then you can send > the whole branch for review, which will open a new review for each of the > changes and then submit them manually. > > Cheers, Lars > > On Fri, Mar 15, 2019 at 6:09 PM Quanlong Huang <[email protected]> > wrote: > > > I thought all the submits to 2.x and master branch should be done in > > Gerrit. Do you mean I can create a new branch manually with the next 10 > > patches, and then merge it *manually* to branch 2.x after > > parallel-all-tests run successfully on it? > > > > -- > > Quanlong > > > > On Sat, Mar 16, 2019 at 12:17 AM Lars Volker <[email protected]> wrote: > > > > > The Jenkins job uses compare_branches.py > > > <https://github.com/apache/impala/blob/2.x/bin/compare_branches.py> to > > do > > > the cherry picking. That script takes source_branch and target_branch > > > parameters, but they need to be valid keys into the ignored commits > file. > > > You'd probably want to amend that script to take a commit up until > which > > > you want to pick. Alternatively you could do the picking manually by > > > passing a list of the commits from your spreadsheet into "git commit" > (it > > > can handle multiple commits at once). Then just run parallel-all-tests > on > > > it. > > > > > > Let me know if you need help with triggering any of this. > > > > > > Cheers, Lars > > > > > > On Fri, Mar 15, 2019 at 8:37 AM Quanlong Huang < > [email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > Branch 2.x is now at 193a1b5. See more details: > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/12h1rTAPS1gm0vhlDGxeOXjnRD7rrOcoqzX4rjRRCyBg > > > > > > > > I got a trouble that the cherrypick-2.x-and-test job is able to > cleanly > > > > pick the next 15 patches but build fail due to a patch in the middle > > > > (f16436628). It needs some changes to fix the test. But I can't > submit > > > the > > > > new patch until branch 2.x has picked the patch before it. > > > > > > > > Is it possible to add a parameter in job cherrypick-2.x-and-test, to > > tell > > > > it that don't consider patches after a commit? So I can let > > > > cherrypick-2.x-and-test > > > > pick only the next 10 patches and submit a new patch for the fix > later. > > > > > > > > Thanks, > > > > Quanlong > > > > > > > > > >
