Hi Zoltan, As you may have noticed, the test addressed in IMPALA-7148 was marked as 'xfail' before the fix of IMPALA-4063 so cherry-picking IMPALA-7148 should have no material effect to that test without IMPALA-4063.
Thanks, Michael On Mon, Nov 19, 2018 at 8:28 AM Zoltan Borok-Nagy <borokna...@cloudera.com> wrote: > Hey Folks, > > Status of the 3.1.0 release: > > I chose IMPALA-5950 (e3a7027) as branching point, and cherry picked commits > until IMPALA-5031 (067657a) (inclusive range) with the following > exceptions: > > - IMPALA-7213 <https://issues.apache.org/jira/browse/IMPALA-7213>: Port > ReportExecStatus() RPCs to KRPC* (requested not to include, tagged as > 3.2.0)* > - IMPALA-4063 <https://issues.apache.org/jira/browse/IMPALA-4063>: Make > fragment instance reports per-query (or per-host) instead of > per-fragment > instance *(t**agged as 3.2.0, also not a clean cherry-pick)* > - IMPALA-7828 <https://issues.apache.org/jira/browse/IMPALA-7828>: > test_mem_leak() > is flaky *(t**agged as 3.2.0, also not a clean cherry-pick)* > - IMPALA-7477 <https://issues.apache.org/jira/browse/IMPALA-7477>: > Improve > QueryResultSet interface to allow appending a batch of rows at a time > *(t**agged as 3.2.0, **but it could be cleanly cherry-picked**)* > > Although "IMPALA-7148 > <https://issues.apache.org/jira/browse/IMPALA-7148>: > test_profile_fragment_instances > is flaky" is tagged as 3.2.0, I decided to include it since it was a clean > cherry-pick and it only fixes a flaky test. > > *From now on please tag your Jiras' fix version as 3.2.0*, or send me an > email if you want to include your change in 3.1.0. > The release branch can be viewed here: > > https://git-wip-us.apache.org/repos/asf?p=impala.git;a=shortlog;h=refs/heads/branch-3.1.0 > > I'll move on with the process when the docs are ready. > > BR, > Zoltan > > > > > > On Mon, Nov 12, 2018 at 10:14 PM Alexandra Rodoni <arod...@cloudera.com> > wrote: > > > I think about 7 working days will be enough to wrap up the doc work for > > 3.1: > > - TOPN query option > > - SHUTDOWN command > > - TIMEZONE changes > > - Minor release-related work > > > > > > > > On Mon, Nov 12, 2018 at 9:17 AM, Zoltan Borok-Nagy < > > borokna...@cloudera.com> > > wrote: > > > > > Hey Folks, > > > > > > It's been a week since we last talked about the 3.1.0 release. > > > > > > So I guess we'll only leave out the RPC-related commit from Michael. > > > > > > Is it OK if I start the branching and testing tomorrow? > > > Then, I'll cherry-pick the docs-related changes from Alex after they > land > > > in the repo. > > > > > > Or, do you prefer to wait with the branching until the docs-related > > changes > > > are made? > > > This way we'll have more changes in the release. > > > > > > BR, > > > Zoltan > > > > > > > > > > > > On Tue, Nov 6, 2018 at 4:23 PM Zoltan Borok-Nagy < > > borokna...@cloudera.com> > > > wrote: > > > > > > > Thanks for the suggestions. > > > > I wasn't aware of interactive git rebase. It might makes it simpler > to > > > > carry out (a) if there are no conflicts. > > > > > > > > Zoltan > > > > > > > > On Tue, Nov 6, 2018 at 4:06 PM Jim Apple <jbap...@cloudera.com> > wrote: > > > > > > > >> > > > > >> > I just have a technical question about it. Should we > > > >> > a) select an early branching point then do a lot of cherry picks > for > > > the > > > >> > commits we want in and leave out the risky ones > > > >> > b) select a recent branching point then revert the risky commits > on > > > the > > > >> > release branch > > > >> > > > > >> > > > >> I think (a) is easier for someone who is doing some git work on the > > > >> branch, > > > >> but our branches tend to be used once for releases and then rarely > > > touched > > > >> again, so it's not a disaster to do (b). > > > >> > > > > > > > > > > -- Thanks, Michael
