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