subject:"\[VOTE\] Release 2.2.0, release candidate #3"

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-16 Thread Reuven Lax

Retrying the whole step succeeded, so somehow this was an ephemeral error.

On Thu, Nov 16, 2017 at 6:28 PM, Reuven Lax  wrote:

> I've fixed the Python issue - turns out my local path got messed up.
>
> However, mvn release:prepare is now failing with the following. I haven't
> seen this failure before - does anyone know what might be causing it?
>
> [*ERROR*] Failed to execute goal org.apache.maven.plugins:
> maven-release-plugin:2.5.3:prepare *(default-cli)* on project beam-parent:
> *An error is occurred in the checkin process: Exception while executing
> SCM command.*: Detecting the current branch failed: fatal: ref HEAD is
> not a symbolic ref -> *[Help 1]*
>
>
>
>
> On Thu, Nov 16, 2017 at 10:11 AM, Reuven Lax  wrote:
>
>> This is with the CP of Eugene's PR. However Eugene's PR does not touch
>> anything Python.
>>
>> On Thu, Nov 16, 2017 at 10:10 AM, Reuven Lax  wrote:
>>
>>>
>>> mvn -Prelease clean install
>>>
>>>
>>> [*INFO*] *--- *exec-maven-plugin:1.5.0:exec *(setuptools-clean)* @
>>> beam-sdks-python* ---*
>>>
>>> Could not find platform independent libraries 
>>>
>>> Could not find platform dependent libraries 
>>>
>>> Consider setting $PYTHONHOME to [:]
>>>
>>> ImportError: No module named site
>>>
>>> [*ERROR*] Command execution failed.
>>>
>>> org.apache.commons.exec.ExecuteException: Process exited with an error:
>>> 1 (Exit value: 1)
>>>
>>> at org.apache.commons.exec.DefaultExecutor.executeInternal(Defa
>>> ultExecutor.java:404)
>>>
>>> at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecu
>>> tor.java:166)
>>>
>>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
>>>
>>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
>>>
>>> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
>>>
>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>>> o(DefaultBuildPluginManager.java:134)
>>>
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>>> oExecutor.java:208)
>>>
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>>> oExecutor.java:154)
>>>
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>>> oExecutor.java:146)
>>>
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>>> uildProject(LifecycleModuleBuilder.java:117)
>>>
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>>> uildProject(LifecycleModuleBuilder.java:81)
>>>
>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.S
>>> ingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>>
>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>>> (LifecycleStarter.java:128)
>>>
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>>>
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>>>
>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>>>
>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>>>
>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>>>
>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>>
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnha
>>> nced(Launcher.java:289)
>>>
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Lau
>>> ncher.java:229)
>>>
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithEx
>>> itCode(Launcher.java:415)
>>>
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launc
>>> her.java:356)
>>>
>>> On Thu, Nov 16, 2017 at 5:02 AM, Charles Chen 
>>> wrote:
>>>
 Could you send the command you used that produced this error?  I can't
 reproduce it at the tip of the release-2.2.0 branch.

 On Wed, Nov 15, 2017 at 5:34 AM Reuven Lax 
 wrote:

 > I'm trying to do the last CP and cut RC4, but I'm getting a
 compilation
 > failure in Python - "ImportError: No module named site"
 >
 > Did we possibly break the release branch on one of the Python CPs?
 >
 > Reuven
 >
 > On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré <
 j...@nanthrax.net>
 > wrote:
 >
 > > Hi Reuven,
 > >
 > > +1 for RC4, and don't worry: it's part of the process. I prefer to
 have a
 > > long release process than a crappy a release ;) That's exactly the
 > purpose
 > > of review & vote.
 > >
 > > I definitely think that having releases more often will reduce such
 kind
 > > of issue.
 > >
 > > Regards
 > > JB
 > >
 > >
 > > On 11/12/2017 09:04 AM, Reuven

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-16 Thread Reuven Lax

I've fixed the Python issue - turns out my local path got messed up.

However, mvn release:prepare is now failing with the following. I haven't
seen this failure before - does anyone know what might be causing it?

[*ERROR*] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare *(default-cli)*
on project beam-parent: *An error is occurred in the checkin process:
Exception while executing SCM command.*: Detecting the current branch
failed: fatal: ref HEAD is not a symbolic ref -> *[Help 1]*




On Thu, Nov 16, 2017 at 10:11 AM, Reuven Lax  wrote:

> This is with the CP of Eugene's PR. However Eugene's PR does not touch
> anything Python.
>
> On Thu, Nov 16, 2017 at 10:10 AM, Reuven Lax  wrote:
>
>>
>> mvn -Prelease clean install
>>
>>
>> [*INFO*] *--- *exec-maven-plugin:1.5.0:exec *(setuptools-clean)* @
>> beam-sdks-python* ---*
>>
>> Could not find platform independent libraries 
>>
>> Could not find platform dependent libraries 
>>
>> Consider setting $PYTHONHOME to [:]
>>
>> ImportError: No module named site
>>
>> [*ERROR*] Command execution failed.
>>
>> org.apache.commons.exec.ExecuteException: Process exited with an error:
>> 1 (Exit value: 1)
>>
>> at org.apache.commons.exec.DefaultExecutor.executeInternal(Defa
>> ultExecutor.java:404)
>>
>> at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecu
>> tor.java:166)
>>
>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
>>
>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
>>
>> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
>>
>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>> o(DefaultBuildPluginManager.java:134)
>>
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:208)
>>
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:154)
>>
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:146)
>>
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>> uildProject(LifecycleModuleBuilder.java:117)
>>
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>> uildProject(LifecycleModuleBuilder.java:81)
>>
>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.S
>> ingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>
>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>> (LifecycleStarter.java:128)
>>
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>>
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>>
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>>
>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>>
>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>>
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>>
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:498)
>>
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnha
>> nced(Launcher.java:289)
>>
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(
>> Launcher.java:229)
>>
>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithEx
>> itCode(Launcher.java:415)
>>
>> at org.codehaus.plexus.classworlds.launcher.Launcher.main(
>> Launcher.java:356)
>>
>> On Thu, Nov 16, 2017 at 5:02 AM, Charles Chen 
>> wrote:
>>
>>> Could you send the command you used that produced this error?  I can't
>>> reproduce it at the tip of the release-2.2.0 branch.
>>>
>>> On Wed, Nov 15, 2017 at 5:34 AM Reuven Lax 
>>> wrote:
>>>
>>> > I'm trying to do the last CP and cut RC4, but I'm getting a compilation
>>> > failure in Python - "ImportError: No module named site"
>>> >
>>> > Did we possibly break the release branch on one of the Python CPs?
>>> >
>>> > Reuven
>>> >
>>> > On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré >> >
>>> > wrote:
>>> >
>>> > > Hi Reuven,
>>> > >
>>> > > +1 for RC4, and don't worry: it's part of the process. I prefer to
>>> have a
>>> > > long release process than a crappy a release ;) That's exactly the
>>> > purpose
>>> > > of review & vote.
>>> > >
>>> > > I definitely think that having releases more often will reduce such
>>> kind
>>> > > of issue.
>>> > >
>>> > > Regards
>>> > > JB
>>> > >
>>> > >
>>> > > On 11/12/2017 09:04 AM, Reuven Lax wrote:
>>> > >
>>> > >> I definitely appreciate the frustration about how long this release
>>> is
>>> > >> taking. It's verging on the point of ridiculous at this point, and
>>> we
>>> > need
>>> > >> to fix some of the things that caused us to get to this state (for
>>> one
>>> > >> thing our

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-15 Thread Reuven Lax

This is with the CP of Eugene's PR. However Eugene's PR does not touch
anything Python.

On Thu, Nov 16, 2017 at 10:10 AM, Reuven Lax  wrote:

>
> mvn -Prelease clean install
>
>
> [*INFO*] *--- *exec-maven-plugin:1.5.0:exec *(setuptools-clean)* @
> beam-sdks-python* ---*
>
> Could not find platform independent libraries 
>
> Could not find platform dependent libraries 
>
> Consider setting $PYTHONHOME to [:]
>
> ImportError: No module named site
>
> [*ERROR*] Command execution failed.
>
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1
> (Exit value: 1)
>
> at org.apache.commons.exec.DefaultExecutor.executeInternal(
> DefaultExecutor.java:404)
>
> at org.apache.commons.exec.DefaultExecutor.execute(
> DefaultExecutor.java:166)
>
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
>
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
>
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
>
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:208)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:154)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:146)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:117)
>
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:81)
>
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.
> SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>
> at org.apache.maven.lifecycle.internal.LifecycleStarter.
> execute(LifecycleStarter.java:128)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launchEnhanced(Launcher.java:289)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launch(Launcher.java:229)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> mainWithExitCode(Launcher.java:415)
>
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> main(Launcher.java:356)
>
> On Thu, Nov 16, 2017 at 5:02 AM, Charles Chen 
> wrote:
>
>> Could you send the command you used that produced this error?  I can't
>> reproduce it at the tip of the release-2.2.0 branch.
>>
>> On Wed, Nov 15, 2017 at 5:34 AM Reuven Lax 
>> wrote:
>>
>> > I'm trying to do the last CP and cut RC4, but I'm getting a compilation
>> > failure in Python - "ImportError: No module named site"
>> >
>> > Did we possibly break the release branch on one of the Python CPs?
>> >
>> > Reuven
>> >
>> > On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré 
>> > wrote:
>> >
>> > > Hi Reuven,
>> > >
>> > > +1 for RC4, and don't worry: it's part of the process. I prefer to
>> have a
>> > > long release process than a crappy a release ;) That's exactly the
>> > purpose
>> > > of review & vote.
>> > >
>> > > I definitely think that having releases more often will reduce such
>> kind
>> > > of issue.
>> > >
>> > > Regards
>> > > JB
>> > >
>> > >
>> > > On 11/12/2017 09:04 AM, Reuven Lax wrote:
>> > >
>> > >> I definitely appreciate the frustration about how long this release
>> is
>> > >> taking. It's verging on the point of ridiculous at this point, and we
>> > need
>> > >> to fix some of the things that caused us to get to this state (for
>> one
>> > >> thing our infrastructure was so busted at one point, that Valentyn
>> > spent 2
>> > >> weeks trying to get on PR merged into the release branch).
>> > >>
>> > >> At this point, let's try and fix this Monday. Unfortunately this is
>> not
>> > >> the
>> > >> sole issue requiring RC4. Python verification failed as well, and we
>> > need
>> > >> an RC4 regardless to merge those PRs. I'm hoping that RC4 is our
>> final
>> > RC,
>> > >> and we can finish voting next week.
>> > >>
>> > >> Reuven
>> > >>
>> > >> On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau <
>> > >> rmannibu...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a
>> > écrit :
>> > >>>
>> > >>> If the purpose is to release 2.2.1 in one

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-15 Thread Reuven Lax

mvn -Prelease clean install


[*INFO*] *--- *exec-maven-plugin:1.5.0:exec *(setuptools-clean)* @
beam-sdks-python* ---*

Could not find platform independent libraries 

Could not find platform dependent libraries 

Consider setting $PYTHONHOME to [:]

ImportError: No module named site

[*ERROR*] Command execution failed.

org.apache.commons.exec.ExecuteException: Process exited with an error: 1
(Exit value: 1)

at
org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)

at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)

at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)

at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)

at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)

at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)

at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)

at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)

at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)

at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)

at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)

at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

On Thu, Nov 16, 2017 at 5:02 AM, Charles Chen 
wrote:

> Could you send the command you used that produced this error?  I can't
> reproduce it at the tip of the release-2.2.0 branch.
>
> On Wed, Nov 15, 2017 at 5:34 AM Reuven Lax 
> wrote:
>
> > I'm trying to do the last CP and cut RC4, but I'm getting a compilation
> > failure in Python - "ImportError: No module named site"
> >
> > Did we possibly break the release branch on one of the Python CPs?
> >
> > Reuven
> >
> > On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi Reuven,
> > >
> > > +1 for RC4, and don't worry: it's part of the process. I prefer to
> have a
> > > long release process than a crappy a release ;) That's exactly the
> > purpose
> > > of review & vote.
> > >
> > > I definitely think that having releases more often will reduce such
> kind
> > > of issue.
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 11/12/2017 09:04 AM, Reuven Lax wrote:
> > >
> > >> I definitely appreciate the frustration about how long this release is
> > >> taking. It's verging on the point of ridiculous at this point, and we
> > need
> > >> to fix some of the things that caused us to get to this state (for one
> > >> thing our infrastructure was so busted at one point, that Valentyn
> > spent 2
> > >> weeks trying to get on PR merged into the release branch).
> > >>
> > >> At this point, let's try and fix this Monday. Unfortunately this is
> not
> > >> the
> > >> sole issue requiring RC4. Python verification failed as well, and we
> > need
> > >> an RC4 regardless to merge those PRs. I'm hoping that RC4 is our final
> > RC,
> > >> and we can finish voting next week.
> > >>
> > >> Reuven
> > >>
> > >> On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >> Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a
> > écrit :
> > >>>
> > >>> If the purpose is to release 2.2.1 in one week, why not just to a
> RC4 ?
> > >>>
> > >>> It's not a regression because WriteFiles is new and extend the
> previous
> > >>> FileSource. So it could consider as a severe bug, especially on
> > >>> WriteFiles
> > >>> which is important.
> > >>>
> > >>>
> > >>> Fair enough.
> > >>>
> > >>>
> > >>> The core issue is the time we spent already on this release: roughly
> 1
> > >>> month !!! It's

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-15 Thread Charles Chen

Could you send the command you used that produced this error?  I can't
reproduce it at the tip of the release-2.2.0 branch.

On Wed, Nov 15, 2017 at 5:34 AM Reuven Lax  wrote:

> I'm trying to do the last CP and cut RC4, but I'm getting a compilation
> failure in Python - "ImportError: No module named site"
>
> Did we possibly break the release branch on one of the Python CPs?
>
> Reuven
>
> On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré 
> wrote:
>
> > Hi Reuven,
> >
> > +1 for RC4, and don't worry: it's part of the process. I prefer to have a
> > long release process than a crappy a release ;) That's exactly the
> purpose
> > of review & vote.
> >
> > I definitely think that having releases more often will reduce such kind
> > of issue.
> >
> > Regards
> > JB
> >
> >
> > On 11/12/2017 09:04 AM, Reuven Lax wrote:
> >
> >> I definitely appreciate the frustration about how long this release is
> >> taking. It's verging on the point of ridiculous at this point, and we
> need
> >> to fix some of the things that caused us to get to this state (for one
> >> thing our infrastructure was so busted at one point, that Valentyn
> spent 2
> >> weeks trying to get on PR merged into the release branch).
> >>
> >> At this point, let's try and fix this Monday. Unfortunately this is not
> >> the
> >> sole issue requiring RC4. Python verification failed as well, and we
> need
> >> an RC4 regardless to merge those PRs. I'm hoping that RC4 is our final
> RC,
> >> and we can finish voting next week.
> >>
> >> Reuven
> >>
> >> On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> wrote:
> >>
> >> Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a
> écrit :
> >>>
> >>> If the purpose is to release 2.2.1 in one week, why not just to a RC4 ?
> >>>
> >>> It's not a regression because WriteFiles is new and extend the previous
> >>> FileSource. So it could consider as a severe bug, especially on
> >>> WriteFiles
> >>> which is important.
> >>>
> >>>
> >>> Fair enough.
> >>>
> >>>
> >>> The core issue is the time we spent already on this release: roughly 1
> >>> month !!! It's clearly too long due to different causes.
> >>> When I did the previous releases, it took 3 or 4 days. It's clearly the
> >>> target as, as said, I would like to have a release pace of a release
> >>> every
> >>> 6 weeks.
> >>>
> >>>
> >>>
> >>> Agree and this is why 2.2.0 must be out now IMHO. If you are confident
> >>> next
> >>> week is sufficient just go ahead and ignore my comment but my point was
> >>> the
> >>> same: it shouldnt last so long if there is no regression :(.
> >>>
> >>>
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 11/11/2017 08:41 AM, Romain Manni-Bucau wrote:
> >>>
> >>> You can see it differently: is there a critical bug? Yes! Is there a
>  regression? No!
> 
>  So no need to wait another week (keep in mind 2 days + 3 days of vote
>  makes easily 1 working week). This vote could be closed already and
> next
>  week 2.2.1 could fix this bug, no? Overall idea is to not hold the
>  community more than needed if there is no regression compared to last
>  few
>  releases.
> 
>  Le 11 nov. 2017 07:46, "Jean-Baptiste Onofré"  a
> écrit
> 
> >>> :
> >>>
> 
>  -1 (binding)
> 
> >
> > I agree with Eugene, data loss is severe.
> >
> > As Eugene seems confident to fix that quickly, I think it's worth to
> >
>  cut a
> >>>
>  RC4.
> >
> > However, I would introduce a deadline. As I would like to propose a
> > release cycle of a release every 6 weeks (whatever it contains, but
> it
> > really important to keep  a regular pace in releases), a release
> should
> >
>  be
> >>>
>  cut in couple of days. So, maybe we can give us 2 business days to fix
> > that
> > and propose a RC4. Basically, if this issue is not fix on Tuesday
> > night,
> > then, we move forward anyway.
> >
> > Regards
> > JB
> >
> > On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:
> >
> > Unfortunately I think I found a data loss bug - it was there since
> > 2.0.0
> >
> >> but I think it's serious enough that delaying a fix until the next
> >> release
> >> would be irresponsible.
> >> See https://issues.apache.org/jira/browse/BEAM-3169
> >>
> >> On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw
> >> 
> >> wrote:
> >>
> >> Our release notes look like nothing more than a query for the closed
> >>
> >> jira issues. Do we have a top-level summary to highlight the big
> >>> ticket items in the release? And in particular somewhere to mention
> >>> that this is likely the last release to support Java 7 that'll get
> >>> widely read?
> >>>
> >>> On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax
>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-15 Thread Reuven Lax

I'm trying to do the last CP and cut RC4, but I'm getting a compilation
failure in Python - "ImportError: No module named site"

Did we possibly break the release branch on one of the Python CPs?

Reuven

On Sun, Nov 12, 2017 at 5:12 PM, Jean-Baptiste Onofré 
wrote:

> Hi Reuven,
>
> +1 for RC4, and don't worry: it's part of the process. I prefer to have a
> long release process than a crappy a release ;) That's exactly the purpose
> of review & vote.
>
> I definitely think that having releases more often will reduce such kind
> of issue.
>
> Regards
> JB
>
>
> On 11/12/2017 09:04 AM, Reuven Lax wrote:
>
>> I definitely appreciate the frustration about how long this release is
>> taking. It's verging on the point of ridiculous at this point, and we need
>> to fix some of the things that caused us to get to this state (for one
>> thing our infrastructure was so busted at one point, that Valentyn spent 2
>> weeks trying to get on PR merged into the release branch).
>>
>> At this point, let's try and fix this Monday. Unfortunately this is not
>> the
>> sole issue requiring RC4. Python verification failed as well, and we need
>> an RC4 regardless to merge those PRs. I'm hoping that RC4 is our final RC,
>> and we can finish voting next week.
>>
>> Reuven
>>
>> On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> wrote:
>>
>> Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a écrit :
>>>
>>> If the purpose is to release 2.2.1 in one week, why not just to a RC4 ?
>>>
>>> It's not a regression because WriteFiles is new and extend the previous
>>> FileSource. So it could consider as a severe bug, especially on
>>> WriteFiles
>>> which is important.
>>>
>>>
>>> Fair enough.
>>>
>>>
>>> The core issue is the time we spent already on this release: roughly 1
>>> month !!! It's clearly too long due to different causes.
>>> When I did the previous releases, it took 3 or 4 days. It's clearly the
>>> target as, as said, I would like to have a release pace of a release
>>> every
>>> 6 weeks.
>>>
>>>
>>>
>>> Agree and this is why 2.2.0 must be out now IMHO. If you are confident
>>> next
>>> week is sufficient just go ahead and ignore my comment but my point was
>>> the
>>> same: it shouldnt last so long if there is no regression :(.
>>>
>>>
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2017 08:41 AM, Romain Manni-Bucau wrote:
>>>
>>> You can see it differently: is there a critical bug? Yes! Is there a
 regression? No!

 So no need to wait another week (keep in mind 2 days + 3 days of vote
 makes easily 1 working week). This vote could be closed already and next
 week 2.2.1 could fix this bug, no? Overall idea is to not hold the
 community more than needed if there is no regression compared to last
 few
 releases.

 Le 11 nov. 2017 07:46, "Jean-Baptiste Onofré"  a écrit

>>> :
>>>

 -1 (binding)

>
> I agree with Eugene, data loss is severe.
>
> As Eugene seems confident to fix that quickly, I think it's worth to
>
 cut a
>>>
 RC4.
>
> However, I would introduce a deadline. As I would like to propose a
> release cycle of a release every 6 weeks (whatever it contains, but it
> really important to keep  a regular pace in releases), a release should
>
 be
>>>
 cut in couple of days. So, maybe we can give us 2 business days to fix
> that
> and propose a RC4. Basically, if this issue is not fix on Tuesday
> night,
> then, we move forward anyway.
>
> Regards
> JB
>
> On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:
>
> Unfortunately I think I found a data loss bug - it was there since
> 2.0.0
>
>> but I think it's serious enough that delaying a fix until the next
>> release
>> would be irresponsible.
>> See https://issues.apache.org/jira/browse/BEAM-3169
>>
>> On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw
>> 
>> wrote:
>>
>> Our release notes look like nothing more than a query for the closed
>>
>> jira issues. Do we have a top-level summary to highlight the big
>>> ticket items in the release? And in particular somewhere to mention
>>> that this is likely the last release to support Java 7 that'll get
>>> widely read?
>>>
>>> On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax >> >
>>> wrote:
>>>
>>> Thanks,
>>>

 This RC is currently failing on a number of validation steps, so we
 need

 to

>>>
>>> cut at least one more RC. Fingers crossed that it will be the last
>>>
>> one.
>>>

 Reuven

 On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
 katsia...@google.com.invalid> wrote:

 Just a remark: Release of Tensorflow Transform

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-12 Thread Jean-Baptiste Onofré


Hi Reuven,

+1 for RC4, and don't worry: it's part of the process. I prefer to have a long 
release process than a crappy a release ;) That's exactly the purpose of review 
& vote.


I definitely think that having releases more often will reduce such kind of 
issue.

Regards
JB

On 11/12/2017 09:04 AM, Reuven Lax wrote:

I definitely appreciate the frustration about how long this release is
taking. It's verging on the point of ridiculous at this point, and we need
to fix some of the things that caused us to get to this state (for one
thing our infrastructure was so busted at one point, that Valentyn spent 2
weeks trying to get on PR merged into the release branch).

At this point, let's try and fix this Monday. Unfortunately this is not the
sole issue requiring RC4. Python verification failed as well, and we need
an RC4 regardless to merge those PRs. I'm hoping that RC4 is our final RC,
and we can finish voting next week.

Reuven

On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau 
wrote:


Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a écrit :

If the purpose is to release 2.2.1 in one week, why not just to a RC4 ?

It's not a regression because WriteFiles is new and extend the previous
FileSource. So it could consider as a severe bug, especially on WriteFiles
which is important.


Fair enough.


The core issue is the time we spent already on this release: roughly 1
month !!! It's clearly too long due to different causes.
When I did the previous releases, it took 3 or 4 days. It's clearly the
target as, as said, I would like to have a release pace of a release every
6 weeks.



Agree and this is why 2.2.0 must be out now IMHO. If you are confident next
week is sufficient just go ahead and ignore my comment but my point was the
same: it shouldnt last so long if there is no regression :(.



Regards
JB


On 11/11/2017 08:41 AM, Romain Manni-Bucau wrote:


You can see it differently: is there a critical bug? Yes! Is there a
regression? No!

So no need to wait another week (keep in mind 2 days + 3 days of vote
makes easily 1 working week). This vote could be closed already and next
week 2.2.1 could fix this bug, no? Overall idea is to not hold the
community more than needed if there is no regression compared to last few
releases.

Le 11 nov. 2017 07:46, "Jean-Baptiste Onofré"  a écrit

:


-1 (binding)


I agree with Eugene, data loss is severe.

As Eugene seems confident to fix that quickly, I think it's worth to

cut a

RC4.

However, I would introduce a deadline. As I would like to propose a
release cycle of a release every 6 weeks (whatever it contains, but it
really important to keep  a regular pace in releases), a release should

be

cut in couple of days. So, maybe we can give us 2 business days to fix
that
and propose a RC4. Basically, if this issue is not fix on Tuesday night,
then, we move forward anyway.

Regards
JB

On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:

Unfortunately I think I found a data loss bug - it was there since 2.0.0

but I think it's serious enough that delaying a fix until the next
release
would be irresponsible.
See https://issues.apache.org/jira/browse/BEAM-3169

On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw

wrote:

Our release notes look like nothing more than a query for the closed


jira issues. Do we have a top-level summary to highlight the big
ticket items in the release? And in particular somewhere to mention
that this is likely the last release to support Java 7 that'll get
widely read?

On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
wrote:

Thanks,


This RC is currently failing on a number of validation steps, so we
need

to


cut at least one more RC. Fingers crossed that it will be the last

one.


Reuven

On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
katsia...@google.com.invalid> wrote:

Just a remark: Release of Tensorflow Transform


 0.4.0 depends on release

of

Apache Beam 2.2.0 so upvoting for a release (the sooner the better).

On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax  wrote:

https://github.com/apache/beam/pull/4109 is out to address both



findings I


reported earlier.


On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <

echauc...@gmail.com>





wrote:





Just as a remark, I compared (on my laptop though) queries



execution





times





on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not


see





any





performance regression.




Best

Etienne


Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :

I looked at Python

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-12 Thread Reuven Lax

I definitely appreciate the frustration about how long this release is
taking. It's verging on the point of ridiculous at this point, and we need
to fix some of the things that caused us to get to this state (for one
thing our infrastructure was so busted at one point, that Valentyn spent 2
weeks trying to get on PR merged into the release branch).

At this point, let's try and fix this Monday. Unfortunately this is not the
sole issue requiring RC4. Python verification failed as well, and we need
an RC4 regardless to merge those PRs. I'm hoping that RC4 is our final RC,
and we can finish voting next week.

Reuven

On Sat, Nov 11, 2017 at 6:24 AM, Romain Manni-Bucau 
wrote:

> Le 11 nov. 2017 09:52, "Jean-Baptiste Onofré"  a écrit :
>
> If the purpose is to release 2.2.1 in one week, why not just to a RC4 ?
>
> It's not a regression because WriteFiles is new and extend the previous
> FileSource. So it could consider as a severe bug, especially on WriteFiles
> which is important.
>
>
> Fair enough.
>
>
> The core issue is the time we spent already on this release: roughly 1
> month !!! It's clearly too long due to different causes.
> When I did the previous releases, it took 3 or 4 days. It's clearly the
> target as, as said, I would like to have a release pace of a release every
> 6 weeks.
>
>
>
> Agree and this is why 2.2.0 must be out now IMHO. If you are confident next
> week is sufficient just go ahead and ignore my comment but my point was the
> same: it shouldnt last so long if there is no regression :(.
>
>
>
> Regards
> JB
>
>
> On 11/11/2017 08:41 AM, Romain Manni-Bucau wrote:
>
> > You can see it differently: is there a critical bug? Yes! Is there a
> > regression? No!
> >
> > So no need to wait another week (keep in mind 2 days + 3 days of vote
> > makes easily 1 working week). This vote could be closed already and next
> > week 2.2.1 could fix this bug, no? Overall idea is to not hold the
> > community more than needed if there is no regression compared to last few
> > releases.
> >
> > Le 11 nov. 2017 07:46, "Jean-Baptiste Onofré"  a écrit
> :
> >
> > -1 (binding)
> >>
> >> I agree with Eugene, data loss is severe.
> >>
> >> As Eugene seems confident to fix that quickly, I think it's worth to
> cut a
> >> RC4.
> >>
> >> However, I would introduce a deadline. As I would like to propose a
> >> release cycle of a release every 6 weeks (whatever it contains, but it
> >> really important to keep  a regular pace in releases), a release should
> be
> >> cut in couple of days. So, maybe we can give us 2 business days to fix
> >> that
> >> and propose a RC4. Basically, if this issue is not fix on Tuesday night,
> >> then, we move forward anyway.
> >>
> >> Regards
> >> JB
> >>
> >> On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:
> >>
> >> Unfortunately I think I found a data loss bug - it was there since 2.0.0
> >>> but I think it's serious enough that delaying a fix until the next
> >>> release
> >>> would be irresponsible.
> >>> See https://issues.apache.org/jira/browse/BEAM-3169
> >>>
> >>> On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw
> >>> 
> >>> wrote:
> >>>
> >>> Our release notes look like nothing more than a query for the closed
> >>>
>  jira issues. Do we have a top-level summary to highlight the big
>  ticket items in the release? And in particular somewhere to mention
>  that this is likely the last release to support Java 7 that'll get
>  widely read?
> 
>  On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
>  wrote:
> 
>  Thanks,
> >
> > This RC is currently failing on a number of validation steps, so we
> > need
> >
> > to
> 
>  cut at least one more RC. Fingers crossed that it will be the last
> one.
> >
> > Reuven
> >
> > On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
> > katsia...@google.com.invalid> wrote:
> >
> > Just a remark: Release of Tensorflow Transform
> >
> >>  0.4.0 depends on release
> of
> >> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
> >>
> >> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax  >
> >> wrote:
> >>
> >> Are we waiting for any more validation of this candidate? If people
> >>
> >>>
> >>> are
> >>
> >
>  still running tests I'll hold off on RC4 (to reduce the chance of an
> >
> >>
> >>> RC5),
> >>
> >> otherwise I'll cut RC4 once Valentyn's PR is merged.
> >>>
> >>> Reuven
> >>>
> >>> On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> >>> valen...@google.com.invalid> wrote:
> >>>
> >>> https://github.com/apache/beam/pull/4109 is out to address both
> >>>
> 
>  findings I
> >>>
> >>> reported earlier.
> 
>  On Thu,

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-11 Thread Jean-Baptiste Onofré


If the purpose is to release 2.2.1 in one week, why not just to a RC4 ?

It's not a regression because WriteFiles is new and extend the previous 
FileSource. So it could consider as a severe bug, especially on WriteFiles which 
is important.


The core issue is the time we spent already on this release: roughly 1 month !!! 
It's clearly too long due to different causes.
When I did the previous releases, it took 3 or 4 days. It's clearly the target 
as, as said, I would like to have a release pace of a release every 6 weeks.


Regards
JB

On 11/11/2017 08:41 AM, Romain Manni-Bucau wrote:

You can see it differently: is there a critical bug? Yes! Is there a
regression? No!

So no need to wait another week (keep in mind 2 days + 3 days of vote
makes easily 1 working week). This vote could be closed already and next
week 2.2.1 could fix this bug, no? Overall idea is to not hold the
community more than needed if there is no regression compared to last few
releases.

Le 11 nov. 2017 07:46, "Jean-Baptiste Onofré"  a écrit :


-1 (binding)

I agree with Eugene, data loss is severe.

As Eugene seems confident to fix that quickly, I think it's worth to cut a
RC4.

However, I would introduce a deadline. As I would like to propose a
release cycle of a release every 6 weeks (whatever it contains, but it
really important to keep  a regular pace in releases), a release should be
cut in couple of days. So, maybe we can give us 2 business days to fix that
and propose a RC4. Basically, if this issue is not fix on Tuesday night,
then, we move forward anyway.

Regards
JB

On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:


Unfortunately I think I found a data loss bug - it was there since 2.0.0
but I think it's serious enough that delaying a fix until the next release
would be irresponsible.
See https://issues.apache.org/jira/browse/BEAM-3169

On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw

wrote:

Our release notes look like nothing more than a query for the closed

jira issues. Do we have a top-level summary to highlight the big
ticket items in the release? And in particular somewhere to mention
that this is likely the last release to support Java 7 that'll get
widely read?

On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
wrote:


Thanks,

This RC is currently failing on a number of validation steps, so we need


to


cut at least one more RC. Fingers crossed that it will be the last one.

Reuven

On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
katsia...@google.com.invalid> wrote:

Just a remark: Release of Tensorflow Transform

 0.4.0 depends on release of
Apache Beam 2.2.0 so upvoting for a release (the sooner the better).

On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax 
wrote:

Are we waiting for any more validation of this candidate? If people



are



still running tests I'll hold off on RC4 (to reduce the chance of an



RC5),


otherwise I'll cut RC4 once Valentyn's PR is merged.

Reuven

On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
valen...@google.com.invalid> wrote:

https://github.com/apache/beam/pull/4109 is out to address both



findings I


reported earlier.

On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <


echauc...@gmail.com>



wrote:


Just as a remark, I compared (on my laptop though) queries



execution



times



on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not


see



any



performance regression.


Best

Etienne


Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :

I looked at Python side of Dataflow & Direct runners on Linux.



There



are



two findings:


1. One of the mobile gaming examples did not pass for Dataflow


runner,



addressed in: https://github.com/apache/beam/pull/4102



.

2. Python streaming did not work for Dataflow runner, one PR is


out



https://github.com/apache/beam/pull/4106, but follow up PRs may



be



required

as we continue to investigate. If we had a PostCommit tests suite


running



against a release branch, this could have been caught earlier.



Filed



https://issues.apache.org/jira/browse/BEAM-3163.


On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-10 Thread Jean-Baptiste Onofré


-1 (binding)

I agree with Eugene, data loss is severe.

As Eugene seems confident to fix that quickly, I think it's worth to cut a RC4.

However, I would introduce a deadline. As I would like to propose a release 
cycle of a release every 6 weeks (whatever it contains, but it really important 
to keep  a regular pace in releases), a release should be cut in couple of days. 
So, maybe we can give us 2 business days to fix that and propose a RC4. 
Basically, if this issue is not fix on Tuesday night, then, we move forward anyway.


Regards
JB

On 11/10/2017 07:42 PM, Eugene Kirpichov wrote:

Unfortunately I think I found a data loss bug - it was there since 2.0.0
but I think it's serious enough that delaying a fix until the next release
would be irresponsible.
See https://issues.apache.org/jira/browse/BEAM-3169

On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw 
wrote:


Our release notes look like nothing more than a query for the closed
jira issues. Do we have a top-level summary to highlight the big
ticket items in the release? And in particular somewhere to mention
that this is likely the last release to support Java 7 that'll get
widely read?

On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
wrote:

Thanks,

This RC is currently failing on a number of validation steps, so we need

to

cut at least one more RC. Fingers crossed that it will be the last one.

Reuven

On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
katsia...@google.com.invalid> wrote:


Just a remark: Release of Tensorflow Transform
 0.4.0 depends on release of
Apache Beam 2.2.0 so upvoting for a release (the sooner the better).

On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax 
wrote:


Are we waiting for any more validation of this candidate? If people

are

still running tests I'll hold off on RC4 (to reduce the chance of an

RC5),

otherwise I'll cut RC4 once Valentyn's PR is merged.

Reuven

On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
valen...@google.com.invalid> wrote:


https://github.com/apache/beam/pull/4109 is out to address both

findings I

reported earlier.

On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <

echauc...@gmail.com>

wrote:


Just as a remark, I compared (on my laptop though) queries

execution

times

on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not

see

any

performance regression.

Best

Etienne


Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :


I looked at Python side of Dataflow & Direct runners on Linux.

There

are

two findings:

1. One of the mobile gaming examples did not pass for Dataflow

runner,

addressed in: https://github.com/apache/beam/pull/4102


.

2. Python streaming did not work for Dataflow runner, one PR is

out

https://github.com/apache/beam/pull/4106, but follow up PRs may

be

required
as we continue to investigate. If we had a PostCommit tests suite

running

against a release branch, this could have been caught earlier.

Filed

https://issues.apache.org/jira/browse/BEAM-3163.

On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax


[6] https://github.com/apache/beam-site/pull/337












--
Gus Katsiapis | Software Engineer | katsia...@google.com | 650-918-7487

<(650)%20918-7487>








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-10 Thread Ted Yu

Considering that the holiday is around the corner, it would be nice to release 
2.2.0 sooner. 
Cheers 
 Original message From: Chamikara Jayalath 
<chamik...@google.com.INVALID> Date: 11/10/17  12:22 PM  (GMT-08:00) To: 
dev@beam.apache.org Subject: Re: [VOTE] Release 2.2.0, release candidate #3 
We found another issue that should probably be fixed in 2.2.0 release:
https://issues.apache.org/jira/browse/BEAM-3172

A fix is out for review and will be merged soon.

Thanks,
Cham

On Fri, Nov 10, 2017 at 10:43 AM Eugene Kirpichov
<kirpic...@google.com.invalid> wrote:

> Unfortunately I think I found a data loss bug - it was there since 2.0.0
> but I think it's serious enough that delaying a fix until the next release
> would be irresponsible.
> See https://issues.apache.org/jira/browse/BEAM-3169
>
> On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw <rober...@google.com.invalid
> >
> wrote:
>
> > Our release notes look like nothing more than a query for the closed
> > jira issues. Do we have a top-level summary to highlight the big
> > ticket items in the release? And in particular somewhere to mention
> > that this is likely the last release to support Java 7 that'll get
> > widely read?
> >
> > On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax <re...@google.com.invalid>
> > wrote:
> > > Thanks,
> > >
> > > This RC is currently failing on a number of validation steps, so we
> need
> > to
> > > cut at least one more RC. Fingers crossed that it will be the last one.
> > >
> > > Reuven
> > >
> > > On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
> > > katsia...@google.com.invalid> wrote:
> > >
> > >> Just a remark: Release of Tensorflow Transform
> > >> <https://github.com/tensorflow/transform> 0.4.0 depends on release of
> > >> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
> > >>
> > >> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax <re...@google.com.invalid>
> > >> wrote:
> > >>
> > >> > Are we waiting for any more validation of this candidate? If people
> > are
> > >> > still running tests I'll hold off on RC4 (to reduce the chance of an
> > >> RC5),
> > >> > otherwise I'll cut RC4 once Valentyn's PR is merged.
> > >> >
> > >> > Reuven
> > >> >
> > >> > On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> > >> > valen...@google.com.invalid> wrote:
> > >> >
> > >> > > https://github.com/apache/beam/pull/4109 is out to address both
> > >> > findings I
> > >> > > reported earlier.
> > >> > >
> > >> > > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <
> > echauc...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Just as a remark, I compared (on my laptop though) queries
> > execution
> > >> > > times
> > >> > > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not
> > see
> > >> > any
> > >> > > > performance regression.
> > >> > > >
> > >> > > > Best
> > >> > > >
> > >> > > > Etienne
> > >> > > >
> > >> > > >
> > >> > > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
> > >> > > >
> > >> > > >> I looked at Python side of Dataflow & Direct runners on Linux.
> > There
> > >> > are
> > >> > > >> two findings:
> > >> > > >>
> > >> > > >> 1. One of the mobile gaming examples did not pass for Dataflow
> > >> runner,
> > >> > > >> addressed in: https://github.com/apache/beam/pull/4102
> > >> > > >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fapa
> > >> > > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
> > >> > > >> CCmOxJj5Gm2uH6g>
> > >> > > >>
> > >> > > >> .
> > >> > > >>
> > >> > > >> 2. Python streaming did not work for Dataflow runner, one PR is
> > out
> > >> > > >> https://github.com/apache/beam/pull/4106, but follow up PRs
> may
> > be
> > >> > > >> required
> > >> > > >

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-10 Thread Romain Manni-Bucau

Both issues are particular cases. Can the 2.2.0 be out and a 2.2.1 done
quickly after? Would be very appreciated to have the 2.2.0 fixes to not
depend on snapshots anymore due to some blockers found in the core of
previous releases.


Le 10 nov. 2017 21:23, "Chamikara Jayalath" 
a écrit :

> We found another issue that should probably be fixed in 2.2.0 release:
> https://issues.apache.org/jira/browse/BEAM-3172
>
> A fix is out for review and will be merged soon.
>
> Thanks,
> Cham
>
> On Fri, Nov 10, 2017 at 10:43 AM Eugene Kirpichov
>  wrote:
>
> > Unfortunately I think I found a data loss bug - it was there since 2.0.0
> > but I think it's serious enough that delaying a fix until the next
> release
> > would be irresponsible.
> > See https://issues.apache.org/jira/browse/BEAM-3169
> >
> > On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw
>  > >
> > wrote:
> >
> > > Our release notes look like nothing more than a query for the closed
> > > jira issues. Do we have a top-level summary to highlight the big
> > > ticket items in the release? And in particular somewhere to mention
> > > that this is likely the last release to support Java 7 that'll get
> > > widely read?
> > >
> > > On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
> > > wrote:
> > > > Thanks,
> > > >
> > > > This RC is currently failing on a number of validation steps, so we
> > need
> > > to
> > > > cut at least one more RC. Fingers crossed that it will be the last
> one.
> > > >
> > > > Reuven
> > > >
> > > > On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
> > > > katsia...@google.com.invalid> wrote:
> > > >
> > > >> Just a remark: Release of Tensorflow Transform
> > > >>  0.4.0 depends on release
> of
> > > >> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
> > > >>
> > > >> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax  >
> > > >> wrote:
> > > >>
> > > >> > Are we waiting for any more validation of this candidate? If
> people
> > > are
> > > >> > still running tests I'll hold off on RC4 (to reduce the chance of
> an
> > > >> RC5),
> > > >> > otherwise I'll cut RC4 once Valentyn's PR is merged.
> > > >> >
> > > >> > Reuven
> > > >> >
> > > >> > On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> > > >> > valen...@google.com.invalid> wrote:
> > > >> >
> > > >> > > https://github.com/apache/beam/pull/4109 is out to address both
> > > >> > findings I
> > > >> > > reported earlier.
> > > >> > >
> > > >> > > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <
> > > echauc...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Just as a remark, I compared (on my laptop though) queries
> > > execution
> > > >> > > times
> > > >> > > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did
> not
> > > see
> > > >> > any
> > > >> > > > performance regression.
> > > >> > > >
> > > >> > > > Best
> > > >> > > >
> > > >> > > > Etienne
> > > >> > > >
> > > >> > > >
> > > >> > > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
> > > >> > > >
> > > >> > > >> I looked at Python side of Dataflow & Direct runners on
> Linux.
> > > There
> > > >> > are
> > > >> > > >> two findings:
> > > >> > > >>
> > > >> > > >> 1. One of the mobile gaming examples did not pass for
> Dataflow
> > > >> runner,
> > > >> > > >> addressed in: https://github.com/apache/beam/pull/4102
> > > >> > > >>  > > >> > > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
> > > >> > > >> CCmOxJj5Gm2uH6g>
> > > >> > > >>
> > > >> > > >> .
> > > >> > > >>
> > > >> > > >> 2. Python streaming did not work for Dataflow runner, one PR
> is
> > > out
> > > >> > > >> https://github.com/apache/beam/pull/4106, but follow up PRs
> > may
> > > be
> > > >> > > >> required
> > > >> > > >> as we continue to investigate. If we had a PostCommit tests
> > suite
> > > >> > > running
> > > >> > > >> against a release branch, this could have been caught
> earlier.
> > > Filed
> > > >> > > >> https://issues.apache.org/jira/browse/BEAM-3163.
> > > >> > > >>
> > > >> > > >> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax
> > >  > > >> >
> > > >> > > >> wrote:
> > > >> > > >>
> > > >> > > >> Hi everyone,
> > > >> > > >>>
> > > >> > > >>> Please review and vote on the release candidate #3 for the
> > > version
> > > >> > > 2.2.0,
> > > >> > > >>> as follows:
> > > >> > > >>>[ ] +1, Approve the release
> > > >> > > >>>[ ] -1, Do not approve the release (please provide
> specific
> > > >> > > comments)
> > > >> > > >>>
> > > >> > > >>>
> > > >> > > >>> The complete staging area is available for your review,
> which
> > > >> > includes:
> > > >> > > >>>* JIRA release notes [1],
> > > >> > > >>>* the official Apache source release to be deployed to
> > > >> > > >>> dist.apache.org
> > > >> > > >>>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-10 Thread Chamikara Jayalath

We found another issue that should probably be fixed in 2.2.0 release:
https://issues.apache.org/jira/browse/BEAM-3172

A fix is out for review and will be merged soon.

Thanks,
Cham

On Fri, Nov 10, 2017 at 10:43 AM Eugene Kirpichov
 wrote:

> Unfortunately I think I found a data loss bug - it was there since 2.0.0
> but I think it's serious enough that delaying a fix until the next release
> would be irresponsible.
> See https://issues.apache.org/jira/browse/BEAM-3169
>
> On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw  >
> wrote:
>
> > Our release notes look like nothing more than a query for the closed
> > jira issues. Do we have a top-level summary to highlight the big
> > ticket items in the release? And in particular somewhere to mention
> > that this is likely the last release to support Java 7 that'll get
> > widely read?
> >
> > On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax 
> > wrote:
> > > Thanks,
> > >
> > > This RC is currently failing on a number of validation steps, so we
> need
> > to
> > > cut at least one more RC. Fingers crossed that it will be the last one.
> > >
> > > Reuven
> > >
> > > On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
> > > katsia...@google.com.invalid> wrote:
> > >
> > >> Just a remark: Release of Tensorflow Transform
> > >>  0.4.0 depends on release of
> > >> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
> > >>
> > >> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax 
> > >> wrote:
> > >>
> > >> > Are we waiting for any more validation of this candidate? If people
> > are
> > >> > still running tests I'll hold off on RC4 (to reduce the chance of an
> > >> RC5),
> > >> > otherwise I'll cut RC4 once Valentyn's PR is merged.
> > >> >
> > >> > Reuven
> > >> >
> > >> > On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> > >> > valen...@google.com.invalid> wrote:
> > >> >
> > >> > > https://github.com/apache/beam/pull/4109 is out to address both
> > >> > findings I
> > >> > > reported earlier.
> > >> > >
> > >> > > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot <
> > echauc...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Just as a remark, I compared (on my laptop though) queries
> > execution
> > >> > > times
> > >> > > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not
> > see
> > >> > any
> > >> > > > performance regression.
> > >> > > >
> > >> > > > Best
> > >> > > >
> > >> > > > Etienne
> > >> > > >
> > >> > > >
> > >> > > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
> > >> > > >
> > >> > > >> I looked at Python side of Dataflow & Direct runners on Linux.
> > There
> > >> > are
> > >> > > >> two findings:
> > >> > > >>
> > >> > > >> 1. One of the mobile gaming examples did not pass for Dataflow
> > >> runner,
> > >> > > >> addressed in: https://github.com/apache/beam/pull/4102
> > >> > > >>  > >> > > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
> > >> > > >> CCmOxJj5Gm2uH6g>
> > >> > > >>
> > >> > > >> .
> > >> > > >>
> > >> > > >> 2. Python streaming did not work for Dataflow runner, one PR is
> > out
> > >> > > >> https://github.com/apache/beam/pull/4106, but follow up PRs
> may
> > be
> > >> > > >> required
> > >> > > >> as we continue to investigate. If we had a PostCommit tests
> suite
> > >> > > running
> > >> > > >> against a release branch, this could have been caught earlier.
> > Filed
> > >> > > >> https://issues.apache.org/jira/browse/BEAM-3163.
> > >> > > >>
> > >> > > >> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax
> >  > >> >
> > >> > > >> wrote:
> > >> > > >>
> > >> > > >> Hi everyone,
> > >> > > >>>
> > >> > > >>> Please review and vote on the release candidate #3 for the
> > version
> > >> > > 2.2.0,
> > >> > > >>> as follows:
> > >> > > >>>[ ] +1, Approve the release
> > >> > > >>>[ ] -1, Do not approve the release (please provide specific
> > >> > > comments)
> > >> > > >>>
> > >> > > >>>
> > >> > > >>> The complete staging area is available for your review, which
> > >> > includes:
> > >> > > >>>* JIRA release notes [1],
> > >> > > >>>* the official Apache source release to be deployed to
> > >> > > >>> dist.apache.org
> > >> > > >>> [2],
> > >> > > >>> which is signed with the key with fingerprint B98B7708 [3],
> > >> > > >>>* all artifacts to be deployed to the Maven Central
> > Repository
> > >> > [4],
> > >> > > >>>* source code tag "v2.2.0-RC3" [5],
> > >> > > >>>* website pull request listing the release and publishing
> the
> > >> API
> > >> > > >>> reference manual [6].
> > >> > > >>>* Java artifacts were built with Maven 3.5.0 and
> > OpenJDK/Oracle
> > >> > JDK
> > >> > > >>> 1.8.0_144.
> > >> > > >>>* Python artifacts are deployed along with the source
> > release to
> > >> > the
> > >> > > >>>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-09 Thread Robert Bradshaw

Our release notes look like nothing more than a query for the closed
jira issues. Do we have a top-level summary to highlight the big
ticket items in the release? And in particular somewhere to mention
that this is likely the last release to support Java 7 that'll get
widely read?

On Thu, Nov 9, 2017 at 3:39 PM, Reuven Lax  wrote:
> Thanks,
>
> This RC is currently failing on a number of validation steps, so we need to
> cut at least one more RC. Fingers crossed that it will be the last one.
>
> Reuven
>
> On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
> katsia...@google.com.invalid> wrote:
>
>> Just a remark: Release of Tensorflow Transform
>>  0.4.0 depends on release of
>> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
>>
>> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax 
>> wrote:
>>
>> > Are we waiting for any more validation of this candidate? If people are
>> > still running tests I'll hold off on RC4 (to reduce the chance of an
>> RC5),
>> > otherwise I'll cut RC4 once Valentyn's PR is merged.
>> >
>> > Reuven
>> >
>> > On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
>> > valen...@google.com.invalid> wrote:
>> >
>> > > https://github.com/apache/beam/pull/4109 is out to address both
>> > findings I
>> > > reported earlier.
>> > >
>> > > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot 
>> > > wrote:
>> > >
>> > > > Just as a remark, I compared (on my laptop though) queries execution
>> > > times
>> > > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not see
>> > any
>> > > > performance regression.
>> > > >
>> > > > Best
>> > > >
>> > > > Etienne
>> > > >
>> > > >
>> > > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
>> > > >
>> > > >> I looked at Python side of Dataflow & Direct runners on Linux. There
>> > are
>> > > >> two findings:
>> > > >>
>> > > >> 1. One of the mobile gaming examples did not pass for Dataflow
>> runner,
>> > > >> addressed in: https://github.com/apache/beam/pull/4102
>> > > >> > > > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
>> > > >> CCmOxJj5Gm2uH6g>
>> > > >>
>> > > >> .
>> > > >>
>> > > >> 2. Python streaming did not work for Dataflow runner, one PR is out
>> > > >> https://github.com/apache/beam/pull/4106, but follow up PRs may be
>> > > >> required
>> > > >> as we continue to investigate. If we had a PostCommit tests suite
>> > > running
>> > > >> against a release branch, this could have been caught earlier. Filed
>> > > >> https://issues.apache.org/jira/browse/BEAM-3163.
>> > > >>
>> > > >> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax > >
>> > > >> wrote:
>> > > >>
>> > > >> Hi everyone,
>> > > >>>
>> > > >>> Please review and vote on the release candidate #3 for the version
>> > > 2.2.0,
>> > > >>> as follows:
>> > > >>>[ ] +1, Approve the release
>> > > >>>[ ] -1, Do not approve the release (please provide specific
>> > > comments)
>> > > >>>
>> > > >>>
>> > > >>> The complete staging area is available for your review, which
>> > includes:
>> > > >>>* JIRA release notes [1],
>> > > >>>* the official Apache source release to be deployed to
>> > > >>> dist.apache.org
>> > > >>> [2],
>> > > >>> which is signed with the key with fingerprint B98B7708 [3],
>> > > >>>* all artifacts to be deployed to the Maven Central Repository
>> > [4],
>> > > >>>* source code tag "v2.2.0-RC3" [5],
>> > > >>>* website pull request listing the release and publishing the
>> API
>> > > >>> reference manual [6].
>> > > >>>* Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle
>> > JDK
>> > > >>> 1.8.0_144.
>> > > >>>* Python artifacts are deployed along with the source release to
>> > the
>> > > >>> dist.apache.org [2].
>> > > >>>
>> > > >>> The vote will be open for at least 72 hours. It is adopted by
>> > majority
>> > > >>> approval, with at least 3 PMC affirmative votes.
>> > > >>>
>> > > >>> Thanks,
>> > > >>> Reuven
>> > > >>>
>> > > >>> [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
>> > > >>> rojectId=12319527=12341044
>> > > >>> [2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
>> > > >>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>> > > >>> [4] https://repository.apache.org/content/repositories/orgapache
>> > > >>> beam-1023/
>> > > >>> [5] https://github.com/apache/beam/tree/v2.2.0-RC3
>> > > >>> 
>> > > >>> [6] https://github.com/apache/beam-site/pull/337
>> > > >>>
>> > > >>>
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> Gus Katsiapis | Software Engineer | katsia...@google.com | 650-918-7487
>>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-09 Thread Reuven Lax

Thanks,

This RC is currently failing on a number of validation steps, so we need to
cut at least one more RC. Fingers crossed that it will be the last one.

Reuven

On Thu, Nov 9, 2017 at 3:36 PM, Konstantinos Katsiapis <
katsia...@google.com.invalid> wrote:

> Just a remark: Release of Tensorflow Transform
>  0.4.0 depends on release of
> Apache Beam 2.2.0 so upvoting for a release (the sooner the better).
>
> On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax 
> wrote:
>
> > Are we waiting for any more validation of this candidate? If people are
> > still running tests I'll hold off on RC4 (to reduce the chance of an
> RC5),
> > otherwise I'll cut RC4 once Valentyn's PR is merged.
> >
> > Reuven
> >
> > On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> > valen...@google.com.invalid> wrote:
> >
> > > https://github.com/apache/beam/pull/4109 is out to address both
> > findings I
> > > reported earlier.
> > >
> > > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot 
> > > wrote:
> > >
> > > > Just as a remark, I compared (on my laptop though) queries execution
> > > times
> > > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not see
> > any
> > > > performance regression.
> > > >
> > > > Best
> > > >
> > > > Etienne
> > > >
> > > >
> > > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
> > > >
> > > >> I looked at Python side of Dataflow & Direct runners on Linux. There
> > are
> > > >> two findings:
> > > >>
> > > >> 1. One of the mobile gaming examples did not pass for Dataflow
> runner,
> > > >> addressed in: https://github.com/apache/beam/pull/4102
> > > >>  > > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
> > > >> CCmOxJj5Gm2uH6g>
> > > >>
> > > >> .
> > > >>
> > > >> 2. Python streaming did not work for Dataflow runner, one PR is out
> > > >> https://github.com/apache/beam/pull/4106, but follow up PRs may be
> > > >> required
> > > >> as we continue to investigate. If we had a PostCommit tests suite
> > > running
> > > >> against a release branch, this could have been caught earlier. Filed
> > > >> https://issues.apache.org/jira/browse/BEAM-3163.
> > > >>
> > > >> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax  >
> > > >> wrote:
> > > >>
> > > >> Hi everyone,
> > > >>>
> > > >>> Please review and vote on the release candidate #3 for the version
> > > 2.2.0,
> > > >>> as follows:
> > > >>>[ ] +1, Approve the release
> > > >>>[ ] -1, Do not approve the release (please provide specific
> > > comments)
> > > >>>
> > > >>>
> > > >>> The complete staging area is available for your review, which
> > includes:
> > > >>>* JIRA release notes [1],
> > > >>>* the official Apache source release to be deployed to
> > > >>> dist.apache.org
> > > >>> [2],
> > > >>> which is signed with the key with fingerprint B98B7708 [3],
> > > >>>* all artifacts to be deployed to the Maven Central Repository
> > [4],
> > > >>>* source code tag "v2.2.0-RC3" [5],
> > > >>>* website pull request listing the release and publishing the
> API
> > > >>> reference manual [6].
> > > >>>* Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle
> > JDK
> > > >>> 1.8.0_144.
> > > >>>* Python artifacts are deployed along with the source release to
> > the
> > > >>> dist.apache.org [2].
> > > >>>
> > > >>> The vote will be open for at least 72 hours. It is adopted by
> > majority
> > > >>> approval, with at least 3 PMC affirmative votes.
> > > >>>
> > > >>> Thanks,
> > > >>> Reuven
> > > >>>
> > > >>> [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
> > > >>> rojectId=12319527=12341044
> > > >>> [2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
> > > >>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> > > >>> [4] https://repository.apache.org/content/repositories/orgapache
> > > >>> beam-1023/
> > > >>> [5] https://github.com/apache/beam/tree/v2.2.0-RC3
> > > >>> 
> > > >>> [6] https://github.com/apache/beam-site/pull/337
> > > >>>
> > > >>>
> > > >
> > >
> >
>
>
>
> --
> Gus Katsiapis | Software Engineer | katsia...@google.com | 650-918-7487
>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-09 Thread Konstantinos Katsiapis

Just a remark: Release of Tensorflow Transform
 0.4.0 depends on release of
Apache Beam 2.2.0 so upvoting for a release (the sooner the better).

On Thu, Nov 9, 2017 at 3:33 PM, Reuven Lax  wrote:

> Are we waiting for any more validation of this candidate? If people are
> still running tests I'll hold off on RC4 (to reduce the chance of an RC5),
> otherwise I'll cut RC4 once Valentyn's PR is merged.
>
> Reuven
>
> On Thu, Nov 9, 2017 at 2:26 PM, Valentyn Tymofieiev <
> valen...@google.com.invalid> wrote:
>
> > https://github.com/apache/beam/pull/4109 is out to address both
> findings I
> > reported earlier.
> >
> > On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot 
> > wrote:
> >
> > > Just as a remark, I compared (on my laptop though) queries execution
> > times
> > > on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not see
> any
> > > performance regression.
> > >
> > > Best
> > >
> > > Etienne
> > >
> > >
> > > Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
> > >
> > >> I looked at Python side of Dataflow & Direct runners on Linux. There
> are
> > >> two findings:
> > >>
> > >> 1. One of the mobile gaming examples did not pass for Dataflow runner,
> > >> addressed in: https://github.com/apache/beam/pull/4102
> > >>  > >> che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
> > >> CCmOxJj5Gm2uH6g>
> > >>
> > >> .
> > >>
> > >> 2. Python streaming did not work for Dataflow runner, one PR is out
> > >> https://github.com/apache/beam/pull/4106, but follow up PRs may be
> > >> required
> > >> as we continue to investigate. If we had a PostCommit tests suite
> > running
> > >> against a release branch, this could have been caught earlier. Filed
> > >> https://issues.apache.org/jira/browse/BEAM-3163.
> > >>
> > >> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax 
> > >> wrote:
> > >>
> > >> Hi everyone,
> > >>>
> > >>> Please review and vote on the release candidate #3 for the version
> > 2.2.0,
> > >>> as follows:
> > >>>[ ] +1, Approve the release
> > >>>[ ] -1, Do not approve the release (please provide specific
> > comments)
> > >>>
> > >>>
> > >>> The complete staging area is available for your review, which
> includes:
> > >>>* JIRA release notes [1],
> > >>>* the official Apache source release to be deployed to
> > >>> dist.apache.org
> > >>> [2],
> > >>> which is signed with the key with fingerprint B98B7708 [3],
> > >>>* all artifacts to be deployed to the Maven Central Repository
> [4],
> > >>>* source code tag "v2.2.0-RC3" [5],
> > >>>* website pull request listing the release and publishing the API
> > >>> reference manual [6].
> > >>>* Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle
> JDK
> > >>> 1.8.0_144.
> > >>>* Python artifacts are deployed along with the source release to
> the
> > >>> dist.apache.org [2].
> > >>>
> > >>> The vote will be open for at least 72 hours. It is adopted by
> majority
> > >>> approval, with at least 3 PMC affirmative votes.
> > >>>
> > >>> Thanks,
> > >>> Reuven
> > >>>
> > >>> [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
> > >>> rojectId=12319527=12341044
> > >>> [2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
> > >>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> > >>> [4] https://repository.apache.org/content/repositories/orgapache
> > >>> beam-1023/
> > >>> [5] https://github.com/apache/beam/tree/v2.2.0-RC3
> > >>> 
> > >>> [6] https://github.com/apache/beam-site/pull/337
> > >>>
> > >>>
> > >
> >
>



-- 
Gus Katsiapis | Software Engineer | katsia...@google.com | 650-918-7487

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-09 Thread Valentyn Tymofieiev

https://github.com/apache/beam/pull/4109 is out to address both findings I
reported earlier.

On Thu, Nov 9, 2017 at 8:54 AM, Etienne Chauchot 
wrote:

> Just as a remark, I compared (on my laptop though) queries execution times
> on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not see any
> performance regression.
>
> Best
>
> Etienne
>
>
> Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :
>
>> I looked at Python side of Dataflow & Direct runners on Linux. There are
>> two findings:
>>
>> 1. One of the mobile gaming examples did not pass for Dataflow runner,
>> addressed in: https://github.com/apache/beam/pull/4102
>> > che%2Fbeam%2Fpull%2F4102=D=1=AFQjCNF3OS6Oo-MeNET
>> CCmOxJj5Gm2uH6g>
>>
>> .
>>
>> 2. Python streaming did not work for Dataflow runner, one PR is out
>> https://github.com/apache/beam/pull/4106, but follow up PRs may be
>> required
>> as we continue to investigate. If we had a PostCommit tests suite running
>> against a release branch, this could have been caught earlier. Filed
>> https://issues.apache.org/jira/browse/BEAM-3163.
>>
>> On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax 
>> wrote:
>>
>> Hi everyone,
>>>
>>> Please review and vote on the release candidate #3 for the version 2.2.0,
>>> as follows:
>>>[ ] +1, Approve the release
>>>[ ] -1, Do not approve the release (please provide specific comments)
>>>
>>>
>>> The complete staging area is available for your review, which includes:
>>>* JIRA release notes [1],
>>>* the official Apache source release to be deployed to
>>> dist.apache.org
>>> [2],
>>> which is signed with the key with fingerprint B98B7708 [3],
>>>* all artifacts to be deployed to the Maven Central Repository [4],
>>>* source code tag "v2.2.0-RC3" [5],
>>>* website pull request listing the release and publishing the API
>>> reference manual [6].
>>>* Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle JDK
>>> 1.8.0_144.
>>>* Python artifacts are deployed along with the source release to the
>>> dist.apache.org [2].
>>>
>>> The vote will be open for at least 72 hours. It is adopted by majority
>>> approval, with at least 3 PMC affirmative votes.
>>>
>>> Thanks,
>>> Reuven
>>>
>>> [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
>>> rojectId=12319527=12341044
>>> [2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
>>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>>> [4] https://repository.apache.org/content/repositories/orgapache
>>> beam-1023/
>>> [5] https://github.com/apache/beam/tree/v2.2.0-RC3
>>> 
>>> [6] https://github.com/apache/beam-site/pull/337
>>>
>>>
>

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-09 Thread Etienne Chauchot

Just as a remark, I compared (on my laptop though) queries execution 
times on my previous run of 2.2.0-RC3 with release 2.1.0 and I did not 
see any performance regression.


Best

Etienne


Le 09/11/2017 à 03:13, Valentyn Tymofieiev a écrit :

I looked at Python side of Dataflow & Direct runners on Linux. There are
two findings:

1. One of the mobile gaming examples did not pass for Dataflow runner,
addressed in: https://github.com/apache/beam/pull/4102

.

2. Python streaming did not work for Dataflow runner, one PR is out
https://github.com/apache/beam/pull/4106, but follow up PRs may be required
as we continue to investigate. If we had a PostCommit tests suite running
against a release branch, this could have been caught earlier. Filed
https://issues.apache.org/jira/browse/BEAM-3163.

On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax  wrote:


Hi everyone,

Please review and vote on the release candidate #3 for the version 2.2.0,
as follows:
   [ ] +1, Approve the release
   [ ] -1, Do not approve the release (please provide specific comments)


The complete staging area is available for your review, which includes:
   * JIRA release notes [1],
   * the official Apache source release to be deployed to dist.apache.org
[2],
which is signed with the key with fingerprint B98B7708 [3],
   * all artifacts to be deployed to the Maven Central Repository [4],
   * source code tag "v2.2.0-RC3" [5],
   * website pull request listing the release and publishing the API
reference manual [6].
   * Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle JDK
1.8.0_144.
   * Python artifacts are deployed along with the source release to the
dist.apache.org [2].

The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.

Thanks,
Reuven

[1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
rojectId=12319527=12341044
[2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
[3] https://dist.apache.org/repos/dist/release/beam/KEYS
[4] https://repository.apache.org/content/repositories/orgapachebeam-1023/
[5] https://github.com/apache/beam/tree/v2.2.0-RC3

[6] https://github.com/apache/beam-site/pull/337

Re: [VOTE] Release 2.2.0, release candidate #3

2017-11-08 Thread Valentyn Tymofieiev

I looked at Python side of Dataflow & Direct runners on Linux. There are
two findings:

1. One of the mobile gaming examples did not pass for Dataflow runner,
addressed in: https://github.com/apache/beam/pull/4102

.

2. Python streaming did not work for Dataflow runner, one PR is out
https://github.com/apache/beam/pull/4106, but follow up PRs may be required
as we continue to investigate. If we had a PostCommit tests suite running
against a release branch, this could have been caught earlier. Filed
https://issues.apache.org/jira/browse/BEAM-3163.

On Wed, Nov 8, 2017 at 2:39 PM, Reuven Lax  wrote:

> Hi everyone,
>
> Please review and vote on the release candidate #3 for the version 2.2.0,
> as follows:
>   [ ] +1, Approve the release
>   [ ] -1, Do not approve the release (please provide specific comments)
>
>
> The complete staging area is available for your review, which includes:
>   * JIRA release notes [1],
>   * the official Apache source release to be deployed to dist.apache.org
> [2],
> which is signed with the key with fingerprint B98B7708 [3],
>   * all artifacts to be deployed to the Maven Central Repository [4],
>   * source code tag "v2.2.0-RC3" [5],
>   * website pull request listing the release and publishing the API
> reference manual [6].
>   * Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle JDK
> 1.8.0_144.
>   * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Reuven
>
> [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
> rojectId=12319527=12341044
> [2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4] https://repository.apache.org/content/repositories/orgapachebeam-1023/
> [5] https://github.com/apache/beam/tree/v2.2.0-RC3
> 
> [6] https://github.com/apache/beam-site/pull/337
>

[VOTE] Release 2.2.0, release candidate #3

2017-11-08 Thread Reuven Lax

Hi everyone,

Please review and vote on the release candidate #3 for the version 2.2.0,
as follows:
  [ ] +1, Approve the release
  [ ] -1, Do not approve the release (please provide specific comments)


The complete staging area is available for your review, which includes:
  * JIRA release notes [1],
  * the official Apache source release to be deployed to dist.apache.org [2],
which is signed with the key with fingerprint B98B7708 [3],
  * all artifacts to be deployed to the Maven Central Repository [4],
  * source code tag "v2.2.0-RC3" [5],
  * website pull request listing the release and publishing the API
reference manual [6].
  * Java artifacts were built with Maven 3.5.0 and OpenJDK/Oracle JDK
1.8.0_144.
  * Python artifacts are deployed along with the source release to the
dist.apache.org [2].

The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.

Thanks,
Reuven

[1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?p
rojectId=12319527=12341044
[2] https://dist.apache.org/repos/dist/dev/beam/2.2.0/
[3] https://dist.apache.org/repos/dist/release/beam/KEYS
[4] https://repository.apache.org/content/repositories/orgapachebeam-1023/
[5] https://github.com/apache/beam/tree/v2.2.0-RC3

[6] https://github.com/apache/beam-site/pull/337

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

Re: [VOTE] Release 2.2.0, release candidate #3

[VOTE] Release 2.2.0, release candidate #3

20 matches

Site Navigation

Mail list logo

Footer information