You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@impala.apache.org by Zoltan Borok-Nagy <bo...@cloudera.com> on 2018/11/05 14:50:53 UTC
[DISCUSS] 3.1.0 release
Hi Folks,
It's been a while since we last released a minor version of Impala.
3.0.0 is out since May, and since then a couple of pretty cool features and
a good number of improvements are checked in.
I propose that we release 3.1.0 soon and I volunteer to be its release
manager. Please speak up and let the community know if anyone has any
objections to this.
Thanks,
Zoltan
Re: [DISCUSS] 3.1.0 release
Posted by Michael Ho <kw...@cloudera.com>.
+1. I concur with Tim that it's safer to leave out this commit
<https://github.com/apache/impala/commit/5391100c7eeb33193de7861e761c3920f1d1eecc>
for
IMPALA-7213 for 3.1 to give it more bake time.
Thanks,
Michael
On Mon, Nov 5, 2018 at 9:32 AM Jim Apple <jb...@cloudera.com> wrote:
> +1. Thanks for volunteering, Zoltan! Do you concur with Tim about leaving
> out some big recent changes, assuming authors request so?
>
> On Mon, Nov 5, 2018 at 9:10 AM Tim Armstrong <ta...@cloudera.com>
> wrote:
>
> > +1
> >
> > I know that I and some other people have been pushing to burn down the
> > critical bugs remaining targeted for 3.1 and push out less critical work
> to
> > 3.2 so we will be in a good position to do a release (it's been a while
> > since 3.0!). I have this filter to track the open JIRAs targeted for 3.1:
> > https://issues.apache.org/jira/issues/?filter=12345062
> >
> > We should figure out the best branching point. Most of the recent commits
> > should go into the release but there are a few larger changes that we
> might
> > want to take on a case-by-case basis. E.g. I'm not sure if Michael Ho
> wants
> > to give some of the RPC changes more time to bake or not.
> >
> > Cheers,
> > Tim
> >
> > On Mon, Nov 5, 2018 at 6:51 AM Zoltan Borok-Nagy <
> boroknagyz@cloudera.com>
> > wrote:
> >
> > > Hi Folks,
> > >
> > > It's been a while since we last released a minor version of Impala.
> > > 3.0.0 is out since May, and since then a couple of pretty cool features
> > and
> > > a good number of improvements are checked in.
> > >
> > > I propose that we release 3.1.0 soon and I volunteer to be its release
> > > manager. Please speak up and let the community know if anyone has any
> > > objections to this.
> > >
> > > Thanks,
> > > Zoltan
> > >
> >
>
--
Thanks,
Michael
Re: [DISCUSS] 3.1.0 release
Posted by Jim Apple <jb...@cloudera.com>.
+1. Thanks for volunteering, Zoltan! Do you concur with Tim about leaving
out some big recent changes, assuming authors request so?
On Mon, Nov 5, 2018 at 9:10 AM Tim Armstrong <ta...@cloudera.com>
wrote:
> +1
>
> I know that I and some other people have been pushing to burn down the
> critical bugs remaining targeted for 3.1 and push out less critical work to
> 3.2 so we will be in a good position to do a release (it's been a while
> since 3.0!). I have this filter to track the open JIRAs targeted for 3.1:
> https://issues.apache.org/jira/issues/?filter=12345062
>
> We should figure out the best branching point. Most of the recent commits
> should go into the release but there are a few larger changes that we might
> want to take on a case-by-case basis. E.g. I'm not sure if Michael Ho wants
> to give some of the RPC changes more time to bake or not.
>
> Cheers,
> Tim
>
> On Mon, Nov 5, 2018 at 6:51 AM Zoltan Borok-Nagy <bo...@cloudera.com>
> wrote:
>
> > Hi Folks,
> >
> > It's been a while since we last released a minor version of Impala.
> > 3.0.0 is out since May, and since then a couple of pretty cool features
> and
> > a good number of improvements are checked in.
> >
> > I propose that we release 3.1.0 soon and I volunteer to be its release
> > manager. Please speak up and let the community know if anyone has any
> > objections to this.
> >
> > Thanks,
> > Zoltan
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Tim Armstrong <ta...@cloudera.com>.
+1
I know that I and some other people have been pushing to burn down the
critical bugs remaining targeted for 3.1 and push out less critical work to
3.2 so we will be in a good position to do a release (it's been a while
since 3.0!). I have this filter to track the open JIRAs targeted for 3.1:
https://issues.apache.org/jira/issues/?filter=12345062
We should figure out the best branching point. Most of the recent commits
should go into the release but there are a few larger changes that we might
want to take on a case-by-case basis. E.g. I'm not sure if Michael Ho wants
to give some of the RPC changes more time to bake or not.
Cheers,
Tim
On Mon, Nov 5, 2018 at 6:51 AM Zoltan Borok-Nagy <bo...@cloudera.com>
wrote:
> Hi Folks,
>
> It's been a while since we last released a minor version of Impala.
> 3.0.0 is out since May, and since then a couple of pretty cool features and
> a good number of improvements are checked in.
>
> I propose that we release 3.1.0 soon and I volunteer to be its release
> manager. Please speak up and let the community know if anyone has any
> objections to this.
>
> Thanks,
> Zoltan
>
Re: [DISCUSS] 3.1.0 release
Posted by Jim Apple <jb...@cloudera.com>.
I think either way is fine.
On Mon, Nov 12, 2018 at 9:17 AM Zoltan Borok-Nagy <bo...@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 <bo...@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 <jb...@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).
> >>
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Philip Zeyliger <ph...@cloudera.com>.
I'd say go for it!
Thanks!
On Mon, Nov 12, 2018 at 9:17 AM Zoltan Borok-Nagy <bo...@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 <bo...@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 <jb...@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).
> >>
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Michael Ho <kw...@cloudera.com>.
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 <bo...@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 <ar...@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 <
> > boroknagyz@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 <
> > boroknagyz@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 <jb...@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
Re: [DISCUSS] 3.1.0 release
Posted by Zoltan Borok-Nagy <bo...@cloudera.com>.
Hi,
Michael:
Thanks, I missed that. I reverted IMPALA-7148 since it is targeted for
3.2.0 and doesn't have any effect without IMPALA-4063.
Alexandra:
Unfortunately I cannot see the image you attached.
Anyway, I also counted 10 new doc commits targeted for 3.1.0:
https://git-wip-us.apache.org/repos/asf?p=impala.git;a=shortlog;h=refs/heads/branch-3.1.0
7d3e9be [DOCS] Copy edits in impala_custom_timezones
9749096 [DOCS] A number of typos were fixed in impala_dedicated_coordinator
3d1afb4 IMPALA-7233: [DOCS] Support for IANA timezone database
df6e92f IMPALA-7815: [DOCS] Release notes for 3.1
3ec779a IMPALA-7861: [DOCS] TLS enabled by default regardless of URI scheme
0d5b5d4 [DOCS] Added a note in impala_scan_bytes_limit.xml
f5348d4 IMPALA-7836: [DOCS] Format changes in impala_topn_bytes_limit.xml
bd573d1 IMPALA-7634: [DOCS] Document the new SHUTDOWN statement
8872e8b IMPALA-7836: [DOCS] Document TOPN_BYTES_LIMIT query option
174ac2f IMPALA-7806: [DOCS] Updated Known Issues in 3.1
So I moved forward to do the RC1, I'll send a [VOTE] mail about it shortly.
*If anyone has objections about the release candidate*, e.g. you want to
add/remove a commit, you can vote with -1 on the RC1.
Thanks,
Zoltan
On Tue, Nov 27, 2018 at 2:23 AM Alexandra Rodoni <ar...@cloudera.com>
wrote:
> I count 10 doc commits since your last cherry-pick:
>
> [image: image.png]
> Thanks!
>
> On Mon, Nov 19, 2018 at 8:28 AM Zoltan Borok-Nagy <bo...@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 <ar...@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 <
>> > boroknagyz@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 <
>> > boroknagyz@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 <jb...@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).
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: [DISCUSS] 3.1.0 release
Posted by Alexandra Rodoni <ar...@cloudera.com>.
I count 10 doc commits since your last cherry-pick:
[image: image.png]
Thanks!
On Mon, Nov 19, 2018 at 8:28 AM Zoltan Borok-Nagy <bo...@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 <ar...@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 <
> > boroknagyz@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 <
> > boroknagyz@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 <jb...@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).
> > > >>
> > > >
> > >
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Zoltan Borok-Nagy <bo...@cloudera.com>.
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 <ar...@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 <
> boroknagyz@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 <
> boroknagyz@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 <jb...@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).
> > >>
> > >
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Alexandra Rodoni <ar...@cloudera.com>.
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 <bo...@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 <bo...@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 <jb...@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).
> >>
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Zoltan Borok-Nagy <bo...@cloudera.com>.
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 <bo...@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 <jb...@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).
>>
>
Re: [DISCUSS] 3.1.0 release
Posted by Zoltan Borok-Nagy <bo...@cloudera.com>.
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 <jb...@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).
>
Re: [DISCUSS] 3.1.0 release
Posted by Jim Apple <jb...@cloudera.com>.
>
> 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).
Re: [DISCUSS] 3.1.0 release
Posted by Gabor Kaszab <ga...@cloudera.com>.
Hey Zoli!
Just a quick comment about the technical part: Isn't it possible to do an
interactive git rebase (-i option) and then you can mark the unwanted
commits as 'drop' in the commit list.
Cheers,
Gabor
On Tue, Nov 6, 2018 at 3:11 PM Zoltan Borok-Nagy <bo...@cloudera.com>
wrote:
> Thanks for the replies. Yeah, it seems reasonable to leave out the risky
> changes.
> 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
>
> Do we have any other commits that we want to leave out?
>
> Thanks for the link, Tim. I think normally we should wait for all the
> blockers, right? However, on a few of them there were no recent activity.
> Do we know the exact list of Jiras we want to wait on? Please speak up if
> you are working on a Jira that you want to push into 3.1.
>
> Alex: I don't think we can start the process this week. It'd be great if we
> could start it next week. However, it largely depends on the progress of
> the ongoing activities.
>
> Thanks,
> Zoltan
>
>
>
> On Mon, Nov 5, 2018 at 8:12 PM Alexandra Rodoni <ar...@cloudera.com>
> wrote:
>
> > Hi Zoltan,
> >
> > When you said, "I propose that we release 3.1.0 soon", how "soon" do you
> > have in mind?
> >
> > I have a few doc tickets for the new features, 3 in reviews, and 3 to
> > start, including the Timezone changes.
> >
> > alex r
> >
> > On Mon, Nov 5, 2018 at 6:50 AM, Zoltan Borok-Nagy <
> boroknagyz@cloudera.com
> > >
> > wrote:
> >
> > > Hi Folks,
> > >
> > > It's been a while since we last released a minor version of Impala.
> > > 3.0.0 is out since May, and since then a couple of pretty cool features
> > and
> > > a good number of improvements are checked in.
> > >
> > > I propose that we release 3.1.0 soon and I volunteer to be its release
> > > manager. Please speak up and let the community know if anyone has any
> > > objections to this.
> > >
> > > Thanks,
> > > Zoltan
> > >
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Zoltan Borok-Nagy <bo...@cloudera.com>.
Thanks for the replies. Yeah, it seems reasonable to leave out the risky
changes.
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
Do we have any other commits that we want to leave out?
Thanks for the link, Tim. I think normally we should wait for all the
blockers, right? However, on a few of them there were no recent activity.
Do we know the exact list of Jiras we want to wait on? Please speak up if
you are working on a Jira that you want to push into 3.1.
Alex: I don't think we can start the process this week. It'd be great if we
could start it next week. However, it largely depends on the progress of
the ongoing activities.
Thanks,
Zoltan
On Mon, Nov 5, 2018 at 8:12 PM Alexandra Rodoni <ar...@cloudera.com>
wrote:
> Hi Zoltan,
>
> When you said, "I propose that we release 3.1.0 soon", how "soon" do you
> have in mind?
>
> I have a few doc tickets for the new features, 3 in reviews, and 3 to
> start, including the Timezone changes.
>
> alex r
>
> On Mon, Nov 5, 2018 at 6:50 AM, Zoltan Borok-Nagy <boroknagyz@cloudera.com
> >
> wrote:
>
> > Hi Folks,
> >
> > It's been a while since we last released a minor version of Impala.
> > 3.0.0 is out since May, and since then a couple of pretty cool features
> and
> > a good number of improvements are checked in.
> >
> > I propose that we release 3.1.0 soon and I volunteer to be its release
> > manager. Please speak up and let the community know if anyone has any
> > objections to this.
> >
> > Thanks,
> > Zoltan
> >
>
Re: [DISCUSS] 3.1.0 release
Posted by Alexandra Rodoni <ar...@cloudera.com>.
Hi Zoltan,
When you said, "I propose that we release 3.1.0 soon", how "soon" do you
have in mind?
I have a few doc tickets for the new features, 3 in reviews, and 3 to
start, including the Timezone changes.
alex r
On Mon, Nov 5, 2018 at 6:50 AM, Zoltan Borok-Nagy <bo...@cloudera.com>
wrote:
> Hi Folks,
>
> It's been a while since we last released a minor version of Impala.
> 3.0.0 is out since May, and since then a couple of pretty cool features and
> a good number of improvements are checked in.
>
> I propose that we release 3.1.0 soon and I volunteer to be its release
> manager. Please speak up and let the community know if anyone has any
> objections to this.
>
> Thanks,
> Zoltan
>