Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-09 Thread Jasper Wang
Hi team,

Just my first very small contribution:

i. By using the SDK 2.5 python dev distribution JB shared, I have just
managed to successfully launch my own custom streaming job on Dataflow.
It's working fine.

ii. this custom streaming reads data from pub/sub, conducts some simple
transformations, then injects data into BigQuery.

FYI.

Cheers.

Jasper

On Sat, Jun 9, 2018 at 9:37 AM, Boyuan Zhang  wrote:

> Hey JB,
>
> We just updated the release guide(https://github.com/
> apache/beam-site/commit/dac24e6bee4b3202fbd33543f9d66e80e8b7cd32). Please
> add your updates to release guide if you want to.
>
> Thanks so much for your help!
>
> Boyuan
>
> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré 
> wrote:
>
>> Thanks, yeah I saw that but I'm planning to add some additional notes.
>>
>> Regards
>> JB
>> Le 5 juin 2018, à 19:02, Boyuan Zhang  a écrit:
>>>
>>> Hey JB,
>>>
>>> We have some updates in :  https://github.com/pabloem/beam-site/blob/
>>> 372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>>> and  https://github.com/apache/beam-site/pull/424/files
>>> .
>>> They may be helpful.
>>>
>>> Boyuan
>>>
>>> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>>> wrote:
>>>
 Was checking if there was something like the release branch of the
 maven release plugin, but there's not with the gradle one.

 I'm creating the branch by hand and I'm updating the release guide in
 the mean time.

 Regards
 JB
 Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" < j...@nanthrax.net> a
 écrit:
>
> On the way
> Le 5 juin 2018, à 18:23, Kenneth Knowles < k...@google.com> a écrit:
>>
>> Have you cut the release branch? It is much easier to stabilize a cut
>> branch that is separated from continued development on master. I think we
>> have to cut it before continuing.
>>
>> Kenn
>>
>> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>> wrote:
>>
>>> Sorry for the noise: this build error was due to a corrupted file in
>>> my
>>> .m2/repository.
>>>
>>> The HDFS extension build is now OK. I'm launching a full build.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>>> > New failure on the build:
>>> >
>>> > FAILURE: Build failed with an exception.
>>> >
>>> > * What went wrong:
>>> > Could not resolve all files for configuration
>>> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>>> >> Could not find zookeeper-tests.jar 
>>> >> (org.apache.zookeeper:zookeeper:3.4.6).
>>>
>>> >   Searched in the following locations:
>>> >
>>> > file:/home/jbonofre/.m2/repository/org/apache/
>>> zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>>> >
>>> > I'm fixing the HDFS extension.
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>>> >> Hi,
>>> >>
>>> >> yes, it's release blocker: the build is not fully stable. I'm
>>> trying to
>>> >> build the release for one week and it fails with different
>>> errors.
>>> >>
>>> >> I have a new build in progress. I hope it will be good. I keep
>>> you posted.
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 05/06/2018 01:38, Scott Wegner wrote:
>>> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
>>> blocking
>>> >>> the release? Let me know if there's anything I can help with.
>>> >>>
>>> >>> [1]  https://the-asf.slack.com/archives/C9H0YNP3P/
>>> p1528133545000136
>>> >>>
>>> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré <
>>> j...@nanthrax.net
>>> >>> > wrote:
>>> >>>
>>> >>> Hi guys,
>>> >>>
>>> >>> just to let you know that the build is now OK. I'm
>>> completing the Jira
>>> >>> triage this morning (my time) and cut the release branch
>>> (starting the
>>> >>> release process). I will validate the release guide in the
>>> mean time.
>>> >>>
>>> >>> Thanks,
>>> >>> Regards
>>> >>> JB
>>> >>>
>>> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> >>> > Hi guys,
>>> >>> >
>>> >>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >>> >
>>> >>> > According to our cycle of release (roughly 6 weeks), we
>>> should
>>> >>> think about 2.5.0.
>>> >>> >
>>> >>> > I'm volunteer to tackle this release.
>>> >>> >
>>> >>> > I'm proposing the following items:
>>> >>> >
>>> >>> > 1. We start the Jira triage now, up to Tuesday
>>> >>> > 2. I would like to cut the release on Tuesday night

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-08 Thread Boyuan Zhang
Hey JB,

We just updated the release guide(
https://github.com/apache/beam-site/commit/dac24e6bee4b3202fbd33543f9d66e80e8b7cd32).
Please add your updates to release guide if you want to.

Thanks so much for your help!

Boyuan

On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré 
wrote:

> Thanks, yeah I saw that but I'm planning to add some additional notes.
>
> Regards
> JB
> Le 5 juin 2018, à 19:02, Boyuan Zhang  a écrit:
>>
>> Hey JB,
>>
>> We have some updates in :  
>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>> and  https://github.com/apache/beam-site/pull/424/files
>> .
>> They may be helpful.
>>
>> Boyuan
>>
>> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>> wrote:
>>
>>> Was checking if there was something like the release branch of the maven
>>> release plugin, but there's not with the gradle one.
>>>
>>> I'm creating the branch by hand and I'm updating the release guide in
>>> the mean time.
>>>
>>> Regards
>>> JB
>>> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" < j...@nanthrax.net> a
>>> écrit:

 On the way
 Le 5 juin 2018, à 18:23, Kenneth Knowles < k...@google.com> a écrit:
>
> Have you cut the release branch? It is much easier to stabilize a cut
> branch that is separated from continued development on master. I think we
> have to cut it before continuing.
>
> Kenn
>
> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré < j...@nanthrax.net>
> wrote:
>
>> Sorry for the noise: this build error was due to a corrupted file in
>> my
>> .m2/repository.
>>
>> The HDFS extension build is now OK. I'm launching a full build.
>>
>> Regards
>> JB
>>
>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>> > New failure on the build:
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * What went wrong:
>> > Could not resolve all files for configuration
>> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>> >> Could not find zookeeper-tests.jar
>> (org.apache.zookeeper:zookeeper:3.4.6).
>> >   Searched in the following locations:
>> >
>> >
>> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>>
>> >
>> > I'm fixing the HDFS extension.
>> >
>> > Regards
>> > JB
>> >
>> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>> >> Hi,
>> >>
>> >> yes, it's release blocker: the build is not fully stable. I'm
>> trying to
>> >> build the release for one week and it fails with different errors.
>> >>
>> >> I have a new build in progress. I hope it will be good. I keep you
>> posted.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 05/06/2018 01:38, Scott Wegner wrote:
>> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
>> blocking
>> >>> the release? Let me know if there's anything I can help with.
>> >>>
>> >>> [1]
>> https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
>> >>>
>> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré <
>> j...@nanthrax.net
>> >>> > wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> just to let you know that the build is now OK. I'm completing
>> the Jira
>> >>> triage this morning (my time) and cut the release branch
>> (starting the
>> >>> release process). I will validate the release guide in the
>> mean time.
>> >>>
>> >>> Thanks,
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> >>> > Hi guys,
>> >>> >
>> >>> > Apache Beam 2.4.0 has been released on March 20th.
>> >>> >
>> >>> > According to our cycle of release (roughly 6 weeks), we
>> should
>> >>> think about 2.5.0.
>> >>> >
>> >>> > I'm volunteer to tackle this release.
>> >>> >
>> >>> > I'm proposing the following items:
>> >>> >
>> >>> > 1. We start the Jira triage now, up to Tuesday
>> >>> > 2. I would like to cut the release on Tuesday night (Europe
>> time)
>> >>> > 2bis. I think it's wiser to still use Maven for this
>> release. Do
>> >>> you think we
>> >>> > will be ready to try a release with Gradle ?
>> >>> >
>> >>> > After this release, I would like a discussion about:
>> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> >>> > 2. Isolate release cycle per Beam part. I think it would be
>> >>> interesting to have
>> >>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
>> another
>> >>> discussion, 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Jean-Baptiste Onofré
The tag is created by the plugin, but it's not pushed on remote.

I had to do:

git push apache v2.5.0.RC1

And yes, I created the branch "manually".

I also did a mvn versions:set on master to update the pom.xml, but not
on the branch (as I focused on gradle release).

Regards
JB

On 06/06/2018 19:29, Pablo Estrada wrote:
> This is because the release plugin that we went with[1] only produces
> release (and release candidate) tags, but it does not create a new
> branch, so the branch itself had to be created manually.
> 
> There were other plugins with the extra branching functionality[2], but
> we decided to use the more popular one.
> 
> [1] https://github.com/researchgate/gradle-release
> [2] https://github.com/nebula-plugins/nebula-release-plugin 
> 
> Best
> -P.
> 
> On Wed, Jun 6, 2018 at 10:21 AM Lukasz Cwik  > wrote:
> 
> I was under the impression that a "release" like plugin was added
> and it was meant to generate the git tag and do other release
> related tasks:
> 
> https://github.com/apache/beam/blob/72cbd99d6b62bc7ed16dbd1288cd61d54e8bda37/build.gradle#L181
> 
> Pablo / Ahmet, do you have more information as it doesn't seem to be
> working?
> 
> On Wed, Jun 6, 2018 at 9:49 AM Jean-Baptiste Onofré  > wrote:
> 
> Hi Scott,
> 
> it contains --no-parallel to test the release, but not to upload
> artifacts.
> 
> --no-daemon is also a must have for all steps.
> 
> There are some missing manual steps to add like pushing the git tag,
> generating the javadoc, ...
> 
> I will update the release guide PR based on what I did for the
> 2.5.0.RC1
> release.
> 
> Regards
> JB
> 
> On 06/06/2018 18:45, Scott Wegner wrote:
> > Tim and Boyuan were previously discussing similar issues in
> the Slack
> > channel [1], and the root cause was related to JAR corruption
> by the
> > signing plugin when using parallel builds. There was also some
> > investigation in BEAM-4328 [2].
> >
> > I believe fixes for all known-issues are now merged. The
> Gradle-based
> > release guide is in review [3] but already includes
> instructions for
> > --no-parallel. If there are still additional issues we should
> create
> > JIRAs for them.
> >
> >
> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1526496272000381 
> > [2] https://issues.apache.org/jira/browse/BEAM-4328 
> > [3] https://github.com/apache/beam-site/pull/424 
> >
> > On Wed, Jun 6, 2018 at 9:13 AM Robert Bradshaw
> mailto:rober...@google.com>
> > >> wrote:
> >
> >     Are there JIRAs filed for these? I have yet to have a
> corrupt cache,
> >     but it would be nice to know how to avoid and fix it.
> >     Did --no-parallel make the ErrorProne error go away? 
> >
> >     On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau
> >     mailto:rmannibu...@gmail.com>
> >>
> wrote:
> >
> >         Also maybe deactivate the daemon (--no-daemon) since
> its cache
> >         can get corrupted ~easily.
> >
> >         Romain Manni-Bucau
> >         @rmannibucau  |  Blog
> >          | Old Blog
> >          | Github
> >          | LinkedIn
> >          | Book
> >       
>  
> 
> >
> >
> >         Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré
> >         mailto:j...@nanthrax.net>
> >> a écrit :
> >
> >             It looks better with --no-parallel
> >
> >             Regards
> >             JB
> >
> >             On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> >             > New issue during:
> >             >
> >             > ./gradlew publish -PisRelease
> >             >
> >             >> Task :beam-runners-apex:compileTestJava
> >             >
> >           
>  
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> >             > error: An unhandled exception was thrown by the
> Error
> >             Prone static
> >             > analysis 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Pablo Estrada
This is because the release plugin that we went with[1] only produces
release (and release candidate) tags, but it does not create a new branch,
so the branch itself had to be created manually.

There were other plugins with the extra branching functionality[2], but we
decided to use the more popular one.

[1] https://github.com/researchgate/gradle-release
[2] https://github.com/nebula-plugins/nebula-release-plugin

Best
-P.

On Wed, Jun 6, 2018 at 10:21 AM Lukasz Cwik  wrote:

> I was under the impression that a "release" like plugin was added and it
> was meant to generate the git tag and do other release related tasks:
>
> https://github.com/apache/beam/blob/72cbd99d6b62bc7ed16dbd1288cd61d54e8bda37/build.gradle#L181
>
> Pablo / Ahmet, do you have more information as it doesn't seem to be
> working?
>
> On Wed, Jun 6, 2018 at 9:49 AM Jean-Baptiste Onofré 
> wrote:
>
>> Hi Scott,
>>
>> it contains --no-parallel to test the release, but not to upload
>> artifacts.
>>
>> --no-daemon is also a must have for all steps.
>>
>> There are some missing manual steps to add like pushing the git tag,
>> generating the javadoc, ...
>>
>> I will update the release guide PR based on what I did for the 2.5.0.RC1
>> release.
>>
>> Regards
>> JB
>>
>> On 06/06/2018 18:45, Scott Wegner wrote:
>> > Tim and Boyuan were previously discussing similar issues in the Slack
>> > channel [1], and the root cause was related to JAR corruption by the
>> > signing plugin when using parallel builds. There was also some
>> > investigation in BEAM-4328 [2].
>> >
>> > I believe fixes for all known-issues are now merged. The Gradle-based
>> > release guide is in review [3] but already includes instructions for
>> > --no-parallel. If there are still additional issues we should create
>> > JIRAs for them.
>> >
>> > [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1526496272000381
>> > [2] https://issues.apache.org/jira/browse/BEAM-4328
>> > [3] https://github.com/apache/beam-site/pull/424
>> >
>> > On Wed, Jun 6, 2018 at 9:13 AM Robert Bradshaw > > > wrote:
>> >
>> > Are there JIRAs filed for these? I have yet to have a corrupt cache,
>> > but it would be nice to know how to avoid and fix it.
>> > Did --no-parallel make the ErrorProne error go away?
>> >
>> > On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau
>> > mailto:rmannibu...@gmail.com>> wrote:
>> >
>> > Also maybe deactivate the daemon (--no-daemon) since its cache
>> > can get corrupted ~easily.
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau  |  Blog
>> >  | Old Blog
>> >  | Github
>> >  | LinkedIn
>> >  | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>> a écrit :
>> >
>> > It looks better with --no-parallel
>> >
>> > Regards
>> > JB
>> >
>> > On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
>> > > New issue during:
>> > >
>> > > ./gradlew publish -PisRelease
>> > >
>> > >> Task :beam-runners-apex:compileTestJava
>> > >
>> >
>>  
>> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
>> > > error: An unhandled exception was thrown by the Error
>> > Prone static
>> > > analysis plugin.
>> > >   public static class StandardStateInternalsTests extends
>> > > StateInternalsTest {
>> > > ^
>> > >  Please report this at
>> > > https://github.com/google/error-prone/issues/new and
>> > include the following:
>> > >
>> > >  error-prone version: 2.3.1
>> > >  BugPattern: HidingField
>> > >  Stack Trace:
>> > >  com.sun.tools.javac.code.ClassFinder$BadClassFile:
>> > bad class file:
>> > >
>> >
>>  
>> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
>> > > unable to access file: java.io.EOFException:
>> > Unexpected end of ZLIB
>> > > input stream
>> > > Please remove or make sure it appears in the correct
>> > subdirectory of
>> > > the classpath.
>> > > at
>> > >
>> >
>>  com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
>> > > at
>> > >
>> >
>>  

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Lukasz Cwik
I was under the impression that a "release" like plugin was added and it
was meant to generate the git tag and do other release related tasks:
https://github.com/apache/beam/blob/72cbd99d6b62bc7ed16dbd1288cd61d54e8bda37/build.gradle#L181

Pablo / Ahmet, do you have more information as it doesn't seem to be
working?

On Wed, Jun 6, 2018 at 9:49 AM Jean-Baptiste Onofré  wrote:

> Hi Scott,
>
> it contains --no-parallel to test the release, but not to upload artifacts.
>
> --no-daemon is also a must have for all steps.
>
> There are some missing manual steps to add like pushing the git tag,
> generating the javadoc, ...
>
> I will update the release guide PR based on what I did for the 2.5.0.RC1
> release.
>
> Regards
> JB
>
> On 06/06/2018 18:45, Scott Wegner wrote:
> > Tim and Boyuan were previously discussing similar issues in the Slack
> > channel [1], and the root cause was related to JAR corruption by the
> > signing plugin when using parallel builds. There was also some
> > investigation in BEAM-4328 [2].
> >
> > I believe fixes for all known-issues are now merged. The Gradle-based
> > release guide is in review [3] but already includes instructions for
> > --no-parallel. If there are still additional issues we should create
> > JIRAs for them.
> >
> > [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1526496272000381
> > [2] https://issues.apache.org/jira/browse/BEAM-4328
> > [3] https://github.com/apache/beam-site/pull/424
> >
> > On Wed, Jun 6, 2018 at 9:13 AM Robert Bradshaw  > > wrote:
> >
> > Are there JIRAs filed for these? I have yet to have a corrupt cache,
> > but it would be nice to know how to avoid and fix it.
> > Did --no-parallel make the ErrorProne error go away?
> >
> > On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau
> > mailto:rmannibu...@gmail.com>> wrote:
> >
> > Also maybe deactivate the daemon (--no-daemon) since its cache
> > can get corrupted ~easily.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>> a écrit :
> >
> > It looks better with --no-parallel
> >
> > Regards
> > JB
> >
> > On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> > > New issue during:
> > >
> > > ./gradlew publish -PisRelease
> > >
> > >> Task :beam-runners-apex:compileTestJava
> > >
> >
>  
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> > > error: An unhandled exception was thrown by the Error
> > Prone static
> > > analysis plugin.
> > >   public static class StandardStateInternalsTests extends
> > > StateInternalsTest {
> > > ^
> > >  Please report this at
> > > https://github.com/google/error-prone/issues/new and
> > include the following:
> > >
> > >  error-prone version: 2.3.1
> > >  BugPattern: HidingField
> > >  Stack Trace:
> > >  com.sun.tools.javac.code.ClassFinder$BadClassFile:
> > bad class file:
> > >
> >
>  
> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
> > > unable to access file: java.io.EOFException:
> > Unexpected end of ZLIB
> > > input stream
> > > Please remove or make sure it appears in the correct
> > subdirectory of
> > > the classpath.
> > > at
> > >
> >
>  com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
> > > at
> > >
> >
>  com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
> > >
> > > I'm trying with --no-parallel.
> > >
> > > Regards
> > > JB
> > >
> > > On 06/06/2018 05:18, Lukasz Cwik wrote:
> > >> JB, I believe many people are waiting on the release to
> > happen and the
> > >> release branch is yet to be cut. It has been almost a
> > week since you
> > >> said you would cut the release branch. It seems like your
> > very busy, can
> > 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Jean-Baptiste Onofré
Hi Scott,

it contains --no-parallel to test the release, but not to upload artifacts.

--no-daemon is also a must have for all steps.

There are some missing manual steps to add like pushing the git tag,
generating the javadoc, ...

I will update the release guide PR based on what I did for the 2.5.0.RC1
release.

Regards
JB

On 06/06/2018 18:45, Scott Wegner wrote:
> Tim and Boyuan were previously discussing similar issues in the Slack
> channel [1], and the root cause was related to JAR corruption by the
> signing plugin when using parallel builds. There was also some
> investigation in BEAM-4328 [2].
> 
> I believe fixes for all known-issues are now merged. The Gradle-based
> release guide is in review [3] but already includes instructions for
> --no-parallel. If there are still additional issues we should create
> JIRAs for them.
> 
> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1526496272000381 
> [2] https://issues.apache.org/jira/browse/BEAM-4328 
> [3] https://github.com/apache/beam-site/pull/424 
> 
> On Wed, Jun 6, 2018 at 9:13 AM Robert Bradshaw  > wrote:
> 
> Are there JIRAs filed for these? I have yet to have a corrupt cache,
> but it would be nice to know how to avoid and fix it.
> Did --no-parallel make the ErrorProne error go away? 
> 
> On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau
> mailto:rmannibu...@gmail.com>> wrote:
> 
> Also maybe deactivate the daemon (--no-daemon) since its cache
> can get corrupted ~easily.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> 
> Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>> a écrit :
> 
> It looks better with --no-parallel
> 
> Regards
> JB
> 
> On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> > New issue during:
> >
> > ./gradlew publish -PisRelease
> >
> >> Task :beam-runners-apex:compileTestJava
> >
> 
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> > error: An unhandled exception was thrown by the Error
> Prone static
> > analysis plugin.
> >   public static class StandardStateInternalsTests extends
> > StateInternalsTest {
> >                 ^
> >      Please report this at
> > https://github.com/google/error-prone/issues/new and
> include the following:
> >
> >      error-prone version: 2.3.1
> >      BugPattern: HidingField
> >      Stack Trace:
> >      com.sun.tools.javac.code.ClassFinder$BadClassFile:
> bad class file:
> >
> 
> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
> >     unable to access file: java.io.EOFException:
> Unexpected end of ZLIB
> > input stream
> >     Please remove or make sure it appears in the correct
> subdirectory of
> > the classpath.
> >         at
> >
> 
> com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
> >         at
> >
> 
> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
> >
> > I'm trying with --no-parallel.
> >
> > Regards
> > JB
> >
> > On 06/06/2018 05:18, Lukasz Cwik wrote:
> >> JB, I believe many people are waiting on the release to
> happen and the
> >> release branch is yet to be cut. It has been almost a
> week since you
> >> said you would cut the release branch. It seems like your
> very busy, can
> >> you explain clearly what is slowing you down so people
> can help or would
> >> you like to defer doing the release at this point in time?
> >>
> >> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> >> >> wrote:
> >>
> >>     Thanks, yeah I saw that but I'm planning to add some
> additional notes.
> >>
> >>     

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Scott Wegner
Tim and Boyuan were previously discussing similar issues in the Slack
channel [1], and the root cause was related to JAR corruption by the
signing plugin when using parallel builds. There was also some
investigation in BEAM-4328 [2].

I believe fixes for all known-issues are now merged. The Gradle-based
release guide is in review [3] but already includes instructions for
--no-parallel. If there are still additional issues we should create JIRAs
for them.

[1] https://the-asf.slack.com/archives/C9H0YNP3P/p1526496272000381
[2] https://issues.apache.org/jira/browse/BEAM-4328
[3] https://github.com/apache/beam-site/pull/424

On Wed, Jun 6, 2018 at 9:13 AM Robert Bradshaw  wrote:

> Are there JIRAs filed for these? I have yet to have a corrupt cache, but
> it would be nice to know how to avoid and fix it. Did --no-parallel make
> the ErrorProne error go away?
>
> On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau 
> wrote:
>
>> Also maybe deactivate the daemon (--no-daemon) since its cache can get
>> corrupted ~easily.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré  a
>> écrit :
>>
>>> It looks better with --no-parallel
>>>
>>> Regards
>>> JB
>>>
>>> On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
>>> > New issue during:
>>> >
>>> > ./gradlew publish -PisRelease
>>> >
>>> >> Task :beam-runners-apex:compileTestJava
>>> >
>>> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
>>> > error: An unhandled exception was thrown by the Error Prone static
>>> > analysis plugin.
>>> >   public static class StandardStateInternalsTests extends
>>> > StateInternalsTest {
>>> > ^
>>> >  Please report this at
>>> > https://github.com/google/error-prone/issues/new and include the
>>> following:
>>> >
>>> >  error-prone version: 2.3.1
>>> >  BugPattern: HidingField
>>> >  Stack Trace:
>>> >  com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
>>> >
>>> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
>>> > unable to access file: java.io.EOFException: Unexpected end of ZLIB
>>> > input stream
>>> > Please remove or make sure it appears in the correct subdirectory
>>> of
>>> > the classpath.
>>> > at
>>> > com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
>>> > at
>>> >
>>> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
>>> >
>>> > I'm trying with --no-parallel.
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 06/06/2018 05:18, Lukasz Cwik wrote:
>>> >> JB, I believe many people are waiting on the release to happen and the
>>> >> release branch is yet to be cut. It has been almost a week since you
>>> >> said you would cut the release branch. It seems like your very busy,
>>> can
>>> >> you explain clearly what is slowing you down so people can help or
>>> would
>>> >> you like to defer doing the release at this point in time?
>>> >>
>>> >> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré >> >> > wrote:
>>> >>
>>> >> Thanks, yeah I saw that but I'm planning to add some additional
>>> notes.
>>> >>
>>> >> Regards
>>> >> JB
>>> >> Le 5 juin 2018, à 19:02, Boyuan Zhang >> >> > a écrit:
>>> >>
>>> >> Hey JB,
>>> >>
>>> >> We have some updates in :
>>> >>
>>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>>> >> <
>>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>>> >and
>>> >> https://github.com/apache/beam-site/pull/424/files
>>> >> <
>>> https://www.google.com/url?q=https://github.com/apache/beam-site/pull/424/files=D=AFQjCNHm8O1DwRKZ1828EQxzmx881O5aWA
>>> >.
>>> >> They may be helpful.
>>> >>
>>> >> Boyuan
>>> >>
>>> >> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
>>> >> j...@nanthrax.net > wrote:
>>> >>
>>> >> Was checking if there was something like the release
>>> branch
>>> >> of the maven release plugin, but there's not with the
>>> gradle
>>> >> one.
>>> >>
>>> >> I'm creating the branch by hand and I'm updating the
>>> release
>>> >> guide in the mean time.
>>> >>
>>> >> Regards
>>> >> JB
>>> >> Le 5 juin 2018, à 18:44, "Jean-Baptiste 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Robert Bradshaw
Are there JIRAs filed for these? I have yet to have a corrupt cache, but it
would be nice to know how to avoid and fix it. Did --no-parallel make the
ErrorProne error go away?

On Tue, Jun 5, 2018 at 11:39 PM Romain Manni-Bucau 
wrote:

> Also maybe deactivate the daemon (--no-daemon) since its cache can get
> corrupted ~easily.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré  a
> écrit :
>
>> It looks better with --no-parallel
>>
>> Regards
>> JB
>>
>> On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
>> > New issue during:
>> >
>> > ./gradlew publish -PisRelease
>> >
>> >> Task :beam-runners-apex:compileTestJava
>> >
>> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
>> > error: An unhandled exception was thrown by the Error Prone static
>> > analysis plugin.
>> >   public static class StandardStateInternalsTests extends
>> > StateInternalsTest {
>> > ^
>> >  Please report this at
>> > https://github.com/google/error-prone/issues/new and include the
>> following:
>> >
>> >  error-prone version: 2.3.1
>> >  BugPattern: HidingField
>> >  Stack Trace:
>> >  com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
>> >
>> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
>> > unable to access file: java.io.EOFException: Unexpected end of ZLIB
>> > input stream
>> > Please remove or make sure it appears in the correct subdirectory of
>> > the classpath.
>> > at
>> > com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
>> > at
>> > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
>> >
>> > I'm trying with --no-parallel.
>> >
>> > Regards
>> > JB
>> >
>> > On 06/06/2018 05:18, Lukasz Cwik wrote:
>> >> JB, I believe many people are waiting on the release to happen and the
>> >> release branch is yet to be cut. It has been almost a week since you
>> >> said you would cut the release branch. It seems like your very busy,
>> can
>> >> you explain clearly what is slowing you down so people can help or
>> would
>> >> you like to defer doing the release at this point in time?
>> >>
>> >> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré > >> > wrote:
>> >>
>> >> Thanks, yeah I saw that but I'm planning to add some additional
>> notes.
>> >>
>> >> Regards
>> >> JB
>> >> Le 5 juin 2018, à 19:02, Boyuan Zhang > >> > a écrit:
>> >>
>> >> Hey JB,
>> >>
>> >> We have some updates in :
>> >>
>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>> >> <
>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>> >and
>> >> https://github.com/apache/beam-site/pull/424/files
>> >> <
>> https://www.google.com/url?q=https://github.com/apache/beam-site/pull/424/files=D=AFQjCNHm8O1DwRKZ1828EQxzmx881O5aWA
>> >.
>> >> They may be helpful.
>> >>
>> >> Boyuan
>> >>
>> >> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
>> >> j...@nanthrax.net > wrote:
>> >>
>> >> Was checking if there was something like the release branch
>> >> of the maven release plugin, but there's not with the
>> gradle
>> >> one.
>> >>
>> >> I'm creating the branch by hand and I'm updating the
>> release
>> >> guide in the mean time.
>> >>
>> >> Regards
>> >> JB
>> >> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
>> >> j...@nanthrax.net > a écrit:
>> >>
>> >> On the way
>> >> Le 5 juin 2018, à 18:23, Kenneth Knowles <
>> >> k...@google.com > a écrit:
>> >>
>> >> Have you cut the release branch? It is much easier
>> >> to stabilize a cut branch that is separated from
>> >> continued development on master. I think we have to
>> >> cut it before continuing.
>> >>
>> >> Kenn
>> >>
>> >> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré
>> >> < j...@nanthrax.net > wrote:
>> >>
>> >> Sorry for the noise: this build 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Jean-Baptiste Onofré
Yup, I disabled the daemon for the release plugin execution.

Regards
JB

On 06/06/2018 08:39, Romain Manni-Bucau wrote:
> Also maybe deactivate the daemon (--no-daemon) since its cache can get
> corrupted ~easily.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré  > a écrit :
> 
> It looks better with --no-parallel
> 
> Regards
> JB
> 
> On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> > New issue during:
> >
> > ./gradlew publish -PisRelease
> >
> >> Task :beam-runners-apex:compileTestJava
> >
> 
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> > error: An unhandled exception was thrown by the Error Prone static
> > analysis plugin.
> >   public static class StandardStateInternalsTests extends
> > StateInternalsTest {
> >                 ^
> >      Please report this at
> > https://github.com/google/error-prone/issues/new and include the
> following:
> >
> >      error-prone version: 2.3.1
> >      BugPattern: HidingField
> >      Stack Trace:
> >      com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class
> file:
> >
> 
> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
> >     unable to access file: java.io.EOFException: Unexpected end of
> ZLIB
> > input stream
> >     Please remove or make sure it appears in the correct
> subdirectory of
> > the classpath.
> >         at
> > com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
> >         at
> >
> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
> >
> > I'm trying with --no-parallel.
> >
> > Regards
> > JB
> >
> > On 06/06/2018 05:18, Lukasz Cwik wrote:
> >> JB, I believe many people are waiting on the release to happen
> and the
> >> release branch is yet to be cut. It has been almost a week since you
> >> said you would cut the release branch. It seems like your very
> busy, can
> >> you explain clearly what is slowing you down so people can help
> or would
> >> you like to defer doing the release at this point in time?
> >>
> >> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> >> >> wrote:
> >>
> >>     Thanks, yeah I saw that but I'm planning to add some
> additional notes.
> >>
> >>     Regards
> >>     JB
> >>     Le 5 juin 2018, à 19:02, Boyuan Zhang  
> >>     >> a écrit:
> >>
> >>         Hey JB,
> >>
> >>         We have some updates in : 
> >>       
>  
> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
> >>       
>  
> and
>  
> >>         https://github.com/apache/beam-site/pull/424/files
> >>       
>  
> .
> >>         They may be helpful.
> >>
> >>         Boyuan
> >>
> >>         On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
> >>         j...@nanthrax.net 
> >> wrote:
> >>
> >>             Was checking if there was something like the release
> branch
> >>             of the maven release plugin, but there's not with the
> gradle
> >>             one.
> >>
> >>             I'm creating the branch by hand and I'm updating the
> release
> >>             guide in the mean time.
> >>
> >>             Regards
> >>             JB
> >>             Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
> >>             j...@nanthrax.net 
> >> a écrit:
> >>
> >>                 On the way
> >>                 Le 5 juin 2018, à 18:23, Kenneth Knowles <
> >>                 k...@google.com 
> >> a écrit:
> >>
>   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Romain Manni-Bucau
Also maybe deactivate the daemon (--no-daemon) since its cache can get
corrupted ~easily.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 6 juin 2018 à 08:35, Jean-Baptiste Onofré  a
écrit :

> It looks better with --no-parallel
>
> Regards
> JB
>
> On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> > New issue during:
> >
> > ./gradlew publish -PisRelease
> >
> >> Task :beam-runners-apex:compileTestJava
> >
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> > error: An unhandled exception was thrown by the Error Prone static
> > analysis plugin.
> >   public static class StandardStateInternalsTests extends
> > StateInternalsTest {
> > ^
> >  Please report this at
> > https://github.com/google/error-prone/issues/new and include the
> following:
> >
> >  error-prone version: 2.3.1
> >  BugPattern: HidingField
> >  Stack Trace:
> >  com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
> >
> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
> > unable to access file: java.io.EOFException: Unexpected end of ZLIB
> > input stream
> > Please remove or make sure it appears in the correct subdirectory of
> > the classpath.
> > at
> > com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
> > at
> > com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
> >
> > I'm trying with --no-parallel.
> >
> > Regards
> > JB
> >
> > On 06/06/2018 05:18, Lukasz Cwik wrote:
> >> JB, I believe many people are waiting on the release to happen and the
> >> release branch is yet to be cut. It has been almost a week since you
> >> said you would cut the release branch. It seems like your very busy, can
> >> you explain clearly what is slowing you down so people can help or would
> >> you like to defer doing the release at this point in time?
> >>
> >> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré  >> > wrote:
> >>
> >> Thanks, yeah I saw that but I'm planning to add some additional
> notes.
> >>
> >> Regards
> >> JB
> >> Le 5 juin 2018, à 19:02, Boyuan Zhang  >> > a écrit:
> >>
> >> Hey JB,
> >>
> >> We have some updates in :
> >>
> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
> >> <
> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
> >and
> >> https://github.com/apache/beam-site/pull/424/files
> >> <
> https://www.google.com/url?q=https://github.com/apache/beam-site/pull/424/files=D=AFQjCNHm8O1DwRKZ1828EQxzmx881O5aWA
> >.
> >> They may be helpful.
> >>
> >> Boyuan
> >>
> >> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
> >> j...@nanthrax.net > wrote:
> >>
> >> Was checking if there was something like the release branch
> >> of the maven release plugin, but there's not with the gradle
> >> one.
> >>
> >> I'm creating the branch by hand and I'm updating the release
> >> guide in the mean time.
> >>
> >> Regards
> >> JB
> >> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
> >> j...@nanthrax.net > a écrit:
> >>
> >> On the way
> >> Le 5 juin 2018, à 18:23, Kenneth Knowles <
> >> k...@google.com > a écrit:
> >>
> >> Have you cut the release branch? It is much easier
> >> to stabilize a cut branch that is separated from
> >> continued development on master. I think we have to
> >> cut it before continuing.
> >>
> >> Kenn
> >>
> >> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré
> >> < j...@nanthrax.net > wrote:
> >>
> >> Sorry for the noise: this build error was due to
> >> a corrupted file in my
> >> .m2/repository.
> >>
> >> The HDFS extension build is now OK. I'm
> >> launching a full build.
> >>
> >> Regards
> >> JB
> >>
> >> On 05/06/2018 07:43, Jean-Baptiste 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-06 Thread Jean-Baptiste Onofré
It looks better with --no-parallel

Regards
JB

On 06/06/2018 07:49, Jean-Baptiste Onofré wrote:
> New issue during:
> 
> ./gradlew publish -PisRelease
> 
>> Task :beam-runners-apex:compileTestJava
> /home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
> error: An unhandled exception was thrown by the Error Prone static
> analysis plugin.
>   public static class StandardStateInternalsTests extends
> StateInternalsTest {
> ^
>  Please report this at
> https://github.com/google/error-prone/issues/new and include the following:
> 
>  error-prone version: 2.3.1
>  BugPattern: HidingField
>  Stack Trace:
>  com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
> /home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
> unable to access file: java.io.EOFException: Unexpected end of ZLIB
> input stream
> Please remove or make sure it appears in the correct subdirectory of
> the classpath.
> at
> com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
> at
> com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)
> 
> I'm trying with --no-parallel.
> 
> Regards
> JB
> 
> On 06/06/2018 05:18, Lukasz Cwik wrote:
>> JB, I believe many people are waiting on the release to happen and the
>> release branch is yet to be cut. It has been almost a week since you
>> said you would cut the release branch. It seems like your very busy, can
>> you explain clearly what is slowing you down so people can help or would
>> you like to defer doing the release at this point in time?
>>
>> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré > > wrote:
>>
>> Thanks, yeah I saw that but I'm planning to add some additional notes.
>>
>> Regards
>> JB
>> Le 5 juin 2018, à 19:02, Boyuan Zhang > > a écrit:
>>
>> Hey JB,
>>
>> We have some updates in : 
>> 
>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>> 
>> and
>>  
>> https://github.com/apache/beam-site/pull/424/files
>> 
>> .
>> They may be helpful.
>>
>> Boyuan
>>
>> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
>> j...@nanthrax.net > wrote:
>>
>> Was checking if there was something like the release branch
>> of the maven release plugin, but there's not with the gradle
>> one.
>>
>> I'm creating the branch by hand and I'm updating the release
>> guide in the mean time.
>>
>> Regards
>> JB
>> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
>> j...@nanthrax.net > a écrit:
>>
>> On the way
>> Le 5 juin 2018, à 18:23, Kenneth Knowles <
>> k...@google.com > a écrit:
>>
>> Have you cut the release branch? It is much easier
>> to stabilize a cut branch that is separated from
>> continued development on master. I think we have to
>> cut it before continuing.
>>
>> Kenn
>>
>> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré
>> < j...@nanthrax.net > wrote:
>>
>> Sorry for the noise: this build error was due to
>> a corrupted file in my
>> .m2/repository.
>>
>> The HDFS extension build is now OK. I'm
>> launching a full build.
>>
>> Regards
>> JB
>>
>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>> > New failure on the build:
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * What went wrong:
>> > Could not resolve all files for configuration
>> >
>> 
>> ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>>
>> >> Could not find zookeeper-tests.jar
>> (org.apache.zookeeper:zookeeper:3.4.6).
>> >   Searched in the following locations:
>> >
>> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
New issue during:

./gradlew publish -PisRelease

> Task :beam-runners-apex:compileTestJava
/home/jbonofre/Workspace/beam/runners/apex/src/test/java/org/apache/beam/runners/apex/translation/utils/ApexStateInternalsTest.java:55:
error: An unhandled exception was thrown by the Error Prone static
analysis plugin.
  public static class StandardStateInternalsTests extends
StateInternalsTest {
^
 Please report this at
https://github.com/google/error-prone/issues/new and include the following:

 error-prone version: 2.3.1
 BugPattern: HidingField
 Stack Trace:
 com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
/home/jbonofre/Workspace/beam/runners/core-java/build/libs/beam-runners-core-java-2.5.0-tests.jar(/org/apache/beam/runners/core/StateInternalsTest$MapEntry.class)
unable to access file: java.io.EOFException: Unexpected end of ZLIB
input stream
Please remove or make sure it appears in the correct subdirectory of
the classpath.
at
com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:298)
at
com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2830)

I'm trying with --no-parallel.

Regards
JB

On 06/06/2018 05:18, Lukasz Cwik wrote:
> JB, I believe many people are waiting on the release to happen and the
> release branch is yet to be cut. It has been almost a week since you
> said you would cut the release branch. It seems like your very busy, can
> you explain clearly what is slowing you down so people can help or would
> you like to defer doing the release at this point in time?
> 
> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré  > wrote:
> 
> Thanks, yeah I saw that but I'm planning to add some additional notes.
> 
> Regards
> JB
> Le 5 juin 2018, à 19:02, Boyuan Zhang  > a écrit:
> 
> Hey JB,
> 
> We have some updates in : 
> 
> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
> 
> and
>  
> https://github.com/apache/beam-site/pull/424/files
> 
> .
> They may be helpful.
> 
> Boyuan
> 
> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
> j...@nanthrax.net > wrote:
> 
> Was checking if there was something like the release branch
> of the maven release plugin, but there's not with the gradle
> one.
> 
> I'm creating the branch by hand and I'm updating the release
> guide in the mean time.
> 
> Regards
> JB
> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
> j...@nanthrax.net > a écrit:
> 
> On the way
> Le 5 juin 2018, à 18:23, Kenneth Knowles <
> k...@google.com > a écrit:
> 
> Have you cut the release branch? It is much easier
> to stabilize a cut branch that is separated from
> continued development on master. I think we have to
> cut it before continuing.
> 
> Kenn
> 
> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré
> < j...@nanthrax.net > wrote:
> 
> Sorry for the noise: this build error was due to
> a corrupted file in my
> .m2/repository.
> 
> The HDFS extension build is now OK. I'm
> launching a full build.
> 
> Regards
> JB
> 
> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
> > New failure on the build:
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Could not resolve all files for configuration
> >
> 
> ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
> 
> >> Could not find zookeeper-tests.jar
> (org.apache.zookeeper:zookeeper:3.4.6).
> >   Searched in the following locations:
> >
> >
> 
> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
> 
> >
> > I'm fixing the HDFS extension.
>   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
Hi Luke,

The delay was simply due to the fact that the build is not stable. I had
many building issue on different tasks. I was not comfortable to cut a
release without a roughly stable build.

Anyway, I moved forward:
- release-2.5.0 branch has been cut and updated
- I also updated master

I already saw mistakes and missing steps in the release guide PR, I will
add notes there.

I keep you posted.

Regards
JB

On 06/06/2018 05:18, Lukasz Cwik wrote:
> JB, I believe many people are waiting on the release to happen and the
> release branch is yet to be cut. It has been almost a week since you
> said you would cut the release branch. It seems like your very busy, can
> you explain clearly what is slowing you down so people can help or would
> you like to defer doing the release at this point in time?
> 
> On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré  > wrote:
> 
> Thanks, yeah I saw that but I'm planning to add some additional notes.
> 
> Regards
> JB
> Le 5 juin 2018, à 19:02, Boyuan Zhang  > a écrit:
> 
> Hey JB,
> 
> We have some updates in : 
> 
> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
> 
> and
>  
> https://github.com/apache/beam-site/pull/424/files
> 
> .
> They may be helpful.
> 
> Boyuan
> 
> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré <
> j...@nanthrax.net > wrote:
> 
> Was checking if there was something like the release branch
> of the maven release plugin, but there's not with the gradle
> one.
> 
> I'm creating the branch by hand and I'm updating the release
> guide in the mean time.
> 
> Regards
> JB
> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" <
> j...@nanthrax.net > a écrit:
> 
> On the way
> Le 5 juin 2018, à 18:23, Kenneth Knowles <
> k...@google.com > a écrit:
> 
> Have you cut the release branch? It is much easier
> to stabilize a cut branch that is separated from
> continued development on master. I think we have to
> cut it before continuing.
> 
> Kenn
> 
> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré
> < j...@nanthrax.net > wrote:
> 
> Sorry for the noise: this build error was due to
> a corrupted file in my
> .m2/repository.
> 
> The HDFS extension build is now OK. I'm
> launching a full build.
> 
> Regards
> JB
> 
> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
> > New failure on the build:
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Could not resolve all files for configuration
> >
> 
> ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
> 
> >> Could not find zookeeper-tests.jar
> (org.apache.zookeeper:zookeeper:3.4.6).
> >   Searched in the following locations:
> >
> >
> 
> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
> 
> >
> > I'm fixing the HDFS extension.
> >
> > Regards
> > JB
> >
> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
> >> Hi,
> >>
> >> yes, it's release blocker: the build is not
> fully stable. I'm trying to
> >> build the release for one week and it fails
> with different errors.
> >>
> >> I have a new build in progress. I hope it
> will be good. I keep you posted.
> >>
> >> Regards
> >> JB
> >>
> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Lukasz Cwik
JB, I believe many people are waiting on the release to happen and the
release branch is yet to be cut. It has been almost a week since you said
you would cut the release branch. It seems like your very busy, can you
explain clearly what is slowing you down so people can help or would you
like to defer doing the release at this point in time?

On Tue, Jun 5, 2018 at 10:16 AM Jean-Baptiste Onofré 
wrote:

> Thanks, yeah I saw that but I'm planning to add some additional notes.
>
> Regards
> JB
> Le 5 juin 2018, à 19:02, Boyuan Zhang  a écrit:
>>
>> Hey JB,
>>
>> We have some updates in :  
>> https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>> and  https://github.com/apache/beam-site/pull/424/files
>> .
>> They may be helpful.
>>
>> Boyuan
>>
>> On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>> wrote:
>>
>>> Was checking if there was something like the release branch of the maven
>>> release plugin, but there's not with the gradle one.
>>>
>>> I'm creating the branch by hand and I'm updating the release guide in
>>> the mean time.
>>>
>>> Regards
>>> JB
>>> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré" < j...@nanthrax.net> a
>>> écrit:

 On the way
 Le 5 juin 2018, à 18:23, Kenneth Knowles < k...@google.com> a écrit:
>
> Have you cut the release branch? It is much easier to stabilize a cut
> branch that is separated from continued development on master. I think we
> have to cut it before continuing.
>
> Kenn
>
> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré < j...@nanthrax.net>
> wrote:
>
>> Sorry for the noise: this build error was due to a corrupted file in
>> my
>> .m2/repository.
>>
>> The HDFS extension build is now OK. I'm launching a full build.
>>
>> Regards
>> JB
>>
>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>> > New failure on the build:
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * What went wrong:
>> > Could not resolve all files for configuration
>> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>> >> Could not find zookeeper-tests.jar
>> (org.apache.zookeeper:zookeeper:3.4.6).
>> >   Searched in the following locations:
>> >
>> >
>> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>>
>> >
>> > I'm fixing the HDFS extension.
>> >
>> > Regards
>> > JB
>> >
>> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>> >> Hi,
>> >>
>> >> yes, it's release blocker: the build is not fully stable. I'm
>> trying to
>> >> build the release for one week and it fails with different errors.
>> >>
>> >> I have a new build in progress. I hope it will be good. I keep you
>> posted.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 05/06/2018 01:38, Scott Wegner wrote:
>> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
>> blocking
>> >>> the release? Let me know if there's anything I can help with.
>> >>>
>> >>> [1]
>> https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
>> >>>
>> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré <
>> j...@nanthrax.net
>> >>> > wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> just to let you know that the build is now OK. I'm completing
>> the Jira
>> >>> triage this morning (my time) and cut the release branch
>> (starting the
>> >>> release process). I will validate the release guide in the
>> mean time.
>> >>>
>> >>> Thanks,
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> >>> > Hi guys,
>> >>> >
>> >>> > Apache Beam 2.4.0 has been released on March 20th.
>> >>> >
>> >>> > According to our cycle of release (roughly 6 weeks), we
>> should
>> >>> think about 2.5.0.
>> >>> >
>> >>> > I'm volunteer to tackle this release.
>> >>> >
>> >>> > I'm proposing the following items:
>> >>> >
>> >>> > 1. We start the Jira triage now, up to Tuesday
>> >>> > 2. I would like to cut the release on Tuesday night (Europe
>> time)
>> >>> > 2bis. I think it's wiser to still use Maven for this
>> release. Do
>> >>> you think we
>> >>> > will be ready to try a release with Gradle ?
>> >>> >
>> >>> > After this release, I would like a discussion about:
>> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> >>> > 2. Isolate release cycle per Beam part. I think it would be
>> >>> interesting to 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
Thanks, yeah I saw that but I'm planning to add some additional notes.

Regards
JB

Le 5 juin 2018 à 19:02, à 19:02, Boyuan Zhang  a écrit:
>Hey JB,
>
>We have some updates in :
>https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
>and https://github.com/apache/beam-site/pull/424/files
>.
>They may be helpful.
>
>Boyuan
>
>On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré 
>wrote:
>
>> Was checking if there was something like the release branch of the
>maven
>> release plugin, but there's not with the gradle one.
>>
>> I'm creating the branch by hand and I'm updating the release guide in
>the
>> mean time.
>>
>> Regards
>> JB
>> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré"  a
>écrit:
>>>
>>> On the way
>>> Le 5 juin 2018, à 18:23, Kenneth Knowles < k...@google.com> a écrit:

 Have you cut the release branch? It is much easier to stabilize a
>cut
 branch that is separated from continued development on master. I
>think we
 have to cut it before continuing.

 Kenn

 On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré <
>j...@nanthrax.net>
 wrote:

> Sorry for the noise: this build error was due to a corrupted file
>in my
> .m2/repository.
>
> The HDFS extension build is now OK. I'm launching a full build.
>
> Regards
> JB
>
> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
> > New failure on the build:
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Could not resolve all files for configuration
> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
> >> Could not find zookeeper-tests.jar
> (org.apache.zookeeper:zookeeper:3.4.6).
> >   Searched in the following locations:
> >
> >
>
>file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>
> >
> > I'm fixing the HDFS extension.
> >
> > Regards
> > JB
> >
> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
> >> Hi,
> >>
> >> yes, it's release blocker: the build is not fully stable. I'm
>trying
> to
> >> build the release for one week and it fails with different
>errors.
> >>
> >> I have a new build in progress. I hope it will be good. I keep
>you
> posted.
> >>
> >> Regards
> >> JB
> >>
> >> On 05/06/2018 01:38, Scott Wegner wrote:
> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
> blocking
> >>> the release? Let me know if there's anything I can help with.
> >>>
> >>> [1]
>https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
>
> >>>
> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> >>> > wrote:
> >>>
> >>> Hi guys,
> >>>
> >>> just to let you know that the build is now OK. I'm
>completing
> the Jira
> >>> triage this morning (my time) and cut the release branch
> (starting the
> >>> release process). I will validate the release guide in the
>mean
> time.
> >>>
> >>> Thanks,
> >>> Regards
> >>> JB
> >>>
> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> >>> > Hi guys,
> >>> >
> >>> > Apache Beam 2.4.0 has been released on March 20th.
> >>> >
> >>> > According to our cycle of release (roughly 6 weeks), we
> should
> >>> think about 2.5.0.
> >>> >
> >>> > I'm volunteer to tackle this release.
> >>> >
> >>> > I'm proposing the following items:
> >>> >
> >>> > 1. We start the Jira triage now, up to Tuesday
> >>> > 2. I would like to cut the release on Tuesday night
>(Europe
> time)
> >>> > 2bis. I think it's wiser to still use Maven for this
>release.
> Do
> >>> you think we
> >>> > will be ready to try a release with Gradle ?
> >>> >
> >>> > After this release, I would like a discussion about:
> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
> >>> > 2. Isolate release cycle per Beam part. I think it would
>be
> >>> interesting to have
> >>> > different release cycle: SDKs, DSLs, Runners, IOs.
>That's
> another
> >>> discussion, I
> >>> > will start a thread about that.
> >>> >
> >>> > Thoughts ?
> >>> >
> >>> > Regards
> >>> > JB
> >>> >
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>>  jbono...@apache.org 
> >>>  http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Boyuan Zhang
Hey JB,

We have some updates in :
https://github.com/pabloem/beam-site/blob/372c93ecbafbf3a1440492df1e12050dfe939e91/src/contribute/release-guide.md
and https://github.com/apache/beam-site/pull/424/files
.
They may be helpful.

Boyuan

On Tue, Jun 5, 2018 at 9:50 AM Jean-Baptiste Onofré  wrote:

> Was checking if there was something like the release branch of the maven
> release plugin, but there's not with the gradle one.
>
> I'm creating the branch by hand and I'm updating the release guide in the
> mean time.
>
> Regards
> JB
> Le 5 juin 2018, à 18:44, "Jean-Baptiste Onofré"  a écrit:
>>
>> On the way
>> Le 5 juin 2018, à 18:23, Kenneth Knowles < k...@google.com> a écrit:
>>>
>>> Have you cut the release branch? It is much easier to stabilize a cut
>>> branch that is separated from continued development on master. I think we
>>> have to cut it before continuing.
>>>
>>> Kenn
>>>
>>> On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>>> wrote:
>>>
 Sorry for the noise: this build error was due to a corrupted file in my
 .m2/repository.

 The HDFS extension build is now OK. I'm launching a full build.

 Regards
 JB

 On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
 > New failure on the build:
 >
 > FAILURE: Build failed with an exception.
 >
 > * What went wrong:
 > Could not resolve all files for configuration
 > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
 >> Could not find zookeeper-tests.jar
 (org.apache.zookeeper:zookeeper:3.4.6).
 >   Searched in the following locations:
 >
 >
 file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar

 >
 > I'm fixing the HDFS extension.
 >
 > Regards
 > JB
 >
 > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
 >> Hi,
 >>
 >> yes, it's release blocker: the build is not fully stable. I'm trying
 to
 >> build the release for one week and it fails with different errors.
 >>
 >> I have a new build in progress. I hope it will be good. I keep you
 posted.
 >>
 >> Regards
 >> JB
 >>
 >> On 05/06/2018 01:38, Scott Wegner wrote:
 >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
 blocking
 >>> the release? Let me know if there's anything I can help with.
 >>>
 >>> [1]  https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136

 >>>
 >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré <
 j...@nanthrax.net
 >>> > wrote:
 >>>
 >>> Hi guys,
 >>>
 >>> just to let you know that the build is now OK. I'm completing
 the Jira
 >>> triage this morning (my time) and cut the release branch
 (starting the
 >>> release process). I will validate the release guide in the mean
 time.
 >>>
 >>> Thanks,
 >>> Regards
 >>> JB
 >>>
 >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
 >>> > Hi guys,
 >>> >
 >>> > Apache Beam 2.4.0 has been released on March 20th.
 >>> >
 >>> > According to our cycle of release (roughly 6 weeks), we
 should
 >>> think about 2.5.0.
 >>> >
 >>> > I'm volunteer to tackle this release.
 >>> >
 >>> > I'm proposing the following items:
 >>> >
 >>> > 1. We start the Jira triage now, up to Tuesday
 >>> > 2. I would like to cut the release on Tuesday night (Europe
 time)
 >>> > 2bis. I think it's wiser to still use Maven for this release.
 Do
 >>> you think we
 >>> > will be ready to try a release with Gradle ?
 >>> >
 >>> > After this release, I would like a discussion about:
 >>> > 1. Gradle release (if we release 2.5.0 with Maven)
 >>> > 2. Isolate release cycle per Beam part. I think it would be
 >>> interesting to have
 >>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
 another
 >>> discussion, I
 >>> > will start a thread about that.
 >>> >
 >>> > Thoughts ?
 >>> >
 >>> > Regards
 >>> > JB
 >>> >
 >>>
 >>> --
 >>> Jean-Baptiste Onofré
 >>>  jbono...@apache.org 
 >>>  http://blog.nanthrax.net
 >>> Talend - http://www.talend.com
 >>>
 >>
 >

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

>>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
Was checking if there was something like the release branch of the maven 
release plugin, but there's not with the gradle one.

I'm creating the branch by hand and I'm updating the release guide in the mean 
time.

Regards
JB

Le 5 juin 2018 à 18:44, à 18:44, "Jean-Baptiste Onofré"  a 
écrit:
>On the way
>
>Le 5 juin 2018 à 18:23, à 18:23, Kenneth Knowles  a
>écrit:
>>Have you cut the release branch? It is much easier to stabilize a cut
>>branch that is separated from continued development on master. I think
>>we
>>have to cut it before continuing.
>>
>>Kenn
>>
>>On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré 
>>wrote:
>>
>>> Sorry for the noise: this build error was due to a corrupted file in
>>my
>>> .m2/repository.
>>>
>>> The HDFS extension build is now OK. I'm launching a full build.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>>> > New failure on the build:
>>> >
>>> > FAILURE: Build failed with an exception.
>>> >
>>> > * What went wrong:
>>> > Could not resolve all files for configuration
>>> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>>> >> Could not find zookeeper-tests.jar
>>> (org.apache.zookeeper:zookeeper:3.4.6).
>>> >   Searched in the following locations:
>>> >
>>> >
>>>
>>file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>>> >
>>> > I'm fixing the HDFS extension.
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>>> >> Hi,
>>> >>
>>> >> yes, it's release blocker: the build is not fully stable. I'm
>>trying to
>>> >> build the release for one week and it fails with different
>errors.
>>> >>
>>> >> I have a new build in progress. I hope it will be good. I keep
>you
>>> posted.
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 05/06/2018 01:38, Scott Wegner wrote:
>>> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
>>blocking
>>> >>> the release? Let me know if there's anything I can help with.
>>> >>>
>>> >>> [1]
>>https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
>>> >>>
>>> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré
 >>> > wrote:
>>> >>>
>>> >>> Hi guys,
>>> >>>
>>> >>> just to let you know that the build is now OK. I'm
>completing
>>the
>>> Jira
>>> >>> triage this morning (my time) and cut the release branch
>>(starting
>>> the
>>> >>> release process). I will validate the release guide in the
>>mean
>>> time.
>>> >>>
>>> >>> Thanks,
>>> >>> Regards
>>> >>> JB
>>> >>>
>>> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> >>> > Hi guys,
>>> >>> >
>>> >>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >>> >
>>> >>> > According to our cycle of release (roughly 6 weeks), we
>>should
>>> >>> think about 2.5.0.
>>> >>> >
>>> >>> > I'm volunteer to tackle this release.
>>> >>> >
>>> >>> > I'm proposing the following items:
>>> >>> >
>>> >>> > 1. We start the Jira triage now, up to Tuesday
>>> >>> > 2. I would like to cut the release on Tuesday night
>(Europe
>>time)
>>> >>> > 2bis. I think it's wiser to still use Maven for this
>>release. Do
>>> >>> you think we
>>> >>> > will be ready to try a release with Gradle ?
>>> >>> >
>>> >>> > After this release, I would like a discussion about:
>>> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
>>> >>> > 2. Isolate release cycle per Beam part. I think it would
>be
>>> >>> interesting to have
>>> >>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
>>another
>>> >>> discussion, I
>>> >>> > will start a thread about that.
>>> >>> >
>>> >>> > Thoughts ?
>>> >>> >
>>> >>> > Regards
>>> >>> > JB
>>> >>> >
>>> >>>
>>> >>> --
>>> >>> Jean-Baptiste Onofré
>>> >>> jbono...@apache.org 
>>> >>> http://blog.nanthrax.net
>>> >>> Talend - http://www.talend.com
>>> >>>
>>> >>
>>> >
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
On the way

Le 5 juin 2018 à 18:23, à 18:23, Kenneth Knowles  a écrit:
>Have you cut the release branch? It is much easier to stabilize a cut
>branch that is separated from continued development on master. I think
>we
>have to cut it before continuing.
>
>Kenn
>
>On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré 
>wrote:
>
>> Sorry for the noise: this build error was due to a corrupted file in
>my
>> .m2/repository.
>>
>> The HDFS extension build is now OK. I'm launching a full build.
>>
>> Regards
>> JB
>>
>> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
>> > New failure on the build:
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * What went wrong:
>> > Could not resolve all files for configuration
>> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>> >> Could not find zookeeper-tests.jar
>> (org.apache.zookeeper:zookeeper:3.4.6).
>> >   Searched in the following locations:
>> >
>> >
>>
>file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>> >
>> > I'm fixing the HDFS extension.
>> >
>> > Regards
>> > JB
>> >
>> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>> >> Hi,
>> >>
>> >> yes, it's release blocker: the build is not fully stable. I'm
>trying to
>> >> build the release for one week and it fails with different errors.
>> >>
>> >> I have a new build in progress. I hope it will be good. I keep you
>> posted.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 05/06/2018 01:38, Scott Wegner wrote:
>> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this
>blocking
>> >>> the release? Let me know if there's anything I can help with.
>> >>>
>> >>> [1]
>https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
>> >>>
>> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré
>> >>> > wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> just to let you know that the build is now OK. I'm completing
>the
>> Jira
>> >>> triage this morning (my time) and cut the release branch
>(starting
>> the
>> >>> release process). I will validate the release guide in the
>mean
>> time.
>> >>>
>> >>> Thanks,
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> >>> > Hi guys,
>> >>> >
>> >>> > Apache Beam 2.4.0 has been released on March 20th.
>> >>> >
>> >>> > According to our cycle of release (roughly 6 weeks), we
>should
>> >>> think about 2.5.0.
>> >>> >
>> >>> > I'm volunteer to tackle this release.
>> >>> >
>> >>> > I'm proposing the following items:
>> >>> >
>> >>> > 1. We start the Jira triage now, up to Tuesday
>> >>> > 2. I would like to cut the release on Tuesday night (Europe
>time)
>> >>> > 2bis. I think it's wiser to still use Maven for this
>release. Do
>> >>> you think we
>> >>> > will be ready to try a release with Gradle ?
>> >>> >
>> >>> > After this release, I would like a discussion about:
>> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> >>> > 2. Isolate release cycle per Beam part. I think it would be
>> >>> interesting to have
>> >>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
>another
>> >>> discussion, I
>> >>> > will start a thread about that.
>> >>> >
>> >>> > Thoughts ?
>> >>> >
>> >>> > Regards
>> >>> > JB
>> >>> >
>> >>>
>> >>> --
>> >>> Jean-Baptiste Onofré
>> >>> jbono...@apache.org 
>> >>> http://blog.nanthrax.net
>> >>> Talend - http://www.talend.com
>> >>>
>> >>
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Kenneth Knowles
Have you cut the release branch? It is much easier to stabilize a cut
branch that is separated from continued development on master. I think we
have to cut it before continuing.

Kenn

On Tue, Jun 5, 2018 at 1:14 AM Jean-Baptiste Onofré  wrote:

> Sorry for the noise: this build error was due to a corrupted file in my
> .m2/repository.
>
> The HDFS extension build is now OK. I'm launching a full build.
>
> Regards
> JB
>
> On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
> > New failure on the build:
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Could not resolve all files for configuration
> > ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
> >> Could not find zookeeper-tests.jar
> (org.apache.zookeeper:zookeeper:3.4.6).
> >   Searched in the following locations:
> >
> >
> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
> >
> > I'm fixing the HDFS extension.
> >
> > Regards
> > JB
> >
> > On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
> >> Hi,
> >>
> >> yes, it's release blocker: the build is not fully stable. I'm trying to
> >> build the release for one week and it fails with different errors.
> >>
> >> I have a new build in progress. I hope it will be good. I keep you
> posted.
> >>
> >> Regards
> >> JB
> >>
> >> On 05/06/2018 01:38, Scott Wegner wrote:
> >>> Hey JB, you mentioned some build issues on Slack [1]. Is this blocking
> >>> the release? Let me know if there's anything I can help with.
> >>>
> >>> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136
> >>>
> >>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré  >>> > wrote:
> >>>
> >>> Hi guys,
> >>>
> >>> just to let you know that the build is now OK. I'm completing the
> Jira
> >>> triage this morning (my time) and cut the release branch (starting
> the
> >>> release process). I will validate the release guide in the mean
> time.
> >>>
> >>> Thanks,
> >>> Regards
> >>> JB
> >>>
> >>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> >>> > Hi guys,
> >>> >
> >>> > Apache Beam 2.4.0 has been released on March 20th.
> >>> >
> >>> > According to our cycle of release (roughly 6 weeks), we should
> >>> think about 2.5.0.
> >>> >
> >>> > I'm volunteer to tackle this release.
> >>> >
> >>> > I'm proposing the following items:
> >>> >
> >>> > 1. We start the Jira triage now, up to Tuesday
> >>> > 2. I would like to cut the release on Tuesday night (Europe time)
> >>> > 2bis. I think it's wiser to still use Maven for this release. Do
> >>> you think we
> >>> > will be ready to try a release with Gradle ?
> >>> >
> >>> > After this release, I would like a discussion about:
> >>> > 1. Gradle release (if we release 2.5.0 with Maven)
> >>> > 2. Isolate release cycle per Beam part. I think it would be
> >>> interesting to have
> >>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> >>> discussion, I
> >>> > will start a thread about that.
> >>> >
> >>> > Thoughts ?
> >>> >
> >>> > Regards
> >>> > JB
> >>> >
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbono...@apache.org 
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-05 Thread Jean-Baptiste Onofré
Sorry for the noise: this build error was due to a corrupted file in my
.m2/repository.

The HDFS extension build is now OK. I'm launching a full build.

Regards
JB

On 05/06/2018 07:43, Jean-Baptiste Onofré wrote:
> New failure on the build:
> 
> FAILURE: Build failed with an exception.
> 
> * What went wrong:
> Could not resolve all files for configuration
> ':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
>> Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6).
>   Searched in the following locations:
> 
> file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
> 
> I'm fixing the HDFS extension.
> 
> Regards
> JB
> 
> On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
>> Hi,
>>
>> yes, it's release blocker: the build is not fully stable. I'm trying to
>> build the release for one week and it fails with different errors.
>>
>> I have a new build in progress. I hope it will be good. I keep you posted.
>>
>> Regards
>> JB
>>
>> On 05/06/2018 01:38, Scott Wegner wrote:
>>> Hey JB, you mentioned some build issues on Slack [1]. Is this blocking
>>> the release? Let me know if there's anything I can help with.
>>>
>>> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136 
>>>
>>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré >> > wrote:
>>>
>>> Hi guys,
>>>
>>> just to let you know that the build is now OK. I'm completing the Jira
>>> triage this morning (my time) and cut the release branch (starting the
>>> release process). I will validate the release guide in the mean time.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> > Hi guys,
>>> >
>>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >
>>> > According to our cycle of release (roughly 6 weeks), we should
>>> think about 2.5.0.
>>> >
>>> > I'm volunteer to tackle this release.
>>> >
>>> > I'm proposing the following items:
>>> >
>>> > 1. We start the Jira triage now, up to Tuesday
>>> > 2. I would like to cut the release on Tuesday night (Europe time)
>>> > 2bis. I think it's wiser to still use Maven for this release. Do
>>> you think we
>>> > will be ready to try a release with Gradle ?
>>> >
>>> > After this release, I would like a discussion about:
>>> > 1. Gradle release (if we release 2.5.0 with Maven)
>>> > 2. Isolate release cycle per Beam part. I think it would be
>>> interesting to have
>>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>> discussion, I
>>> > will start a thread about that.
>>> >
>>> > Thoughts ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>>
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org 
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-04 Thread Jean-Baptiste Onofré
New failure on the build:

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all files for configuration
':beam-sdks-java-io-hadoop-file-system:testCompileClasspath'.
> Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6).
  Searched in the following locations:

file:/home/jbonofre/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar

I'm fixing the HDFS extension.

Regards
JB

On 05/06/2018 07:18, Jean-Baptiste Onofré wrote:
> Hi,
> 
> yes, it's release blocker: the build is not fully stable. I'm trying to
> build the release for one week and it fails with different errors.
> 
> I have a new build in progress. I hope it will be good. I keep you posted.
> 
> Regards
> JB
> 
> On 05/06/2018 01:38, Scott Wegner wrote:
>> Hey JB, you mentioned some build issues on Slack [1]. Is this blocking
>> the release? Let me know if there's anything I can help with.
>>
>> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136 
>>
>> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré > > wrote:
>>
>> Hi guys,
>>
>> just to let you know that the build is now OK. I'm completing the Jira
>> triage this morning (my time) and cut the release branch (starting the
>> release process). I will validate the release guide in the mean time.
>>
>> Thanks,
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should
>> think about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe time)
>> > 2bis. I think it's wiser to still use Maven for this release. Do
>> you think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be
>> interesting to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>>
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org 
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-04 Thread Jean-Baptiste Onofré
Hi,

yes, it's release blocker: the build is not fully stable. I'm trying to
build the release for one week and it fails with different errors.

I have a new build in progress. I hope it will be good. I keep you posted.

Regards
JB

On 05/06/2018 01:38, Scott Wegner wrote:
> Hey JB, you mentioned some build issues on Slack [1]. Is this blocking
> the release? Let me know if there's anything I can help with.
> 
> [1] https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136 
> 
> On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi guys,
> 
> just to let you know that the build is now OK. I'm completing the Jira
> triage this morning (my time) and cut the release branch (starting the
> release process). I will validate the release guide in the mean time.
> 
> Thanks,
> Regards
> JB
> 
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should
> think about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do
> you think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be
> interesting to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-04 Thread Scott Wegner
Hey JB, you mentioned some build issues on Slack [1]. Is this blocking the
release? Let me know if there's anything I can help with.

[1] https://the-asf.slack.com/archives/C9H0YNP3P/p1528133545000136

On Sun, Jun 3, 2018 at 10:58 PM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> just to let you know that the build is now OK. I'm completing the Jira
> triage this morning (my time) and cut the release branch (starting the
> release process). I will validate the release guide in the mean time.
>
> Thanks,
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-03 Thread Jean-Baptiste Onofré
Hi guys,

just to let you know that the build is now OK. I'm completing the Jira
triage this morning (my time) and cut the release branch (starting the
release process). I will validate the release guide in the mean time.

Thanks,
Regards
JB

On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> Apache Beam 2.4.0 has been released on March 20th.
> 
> According to our cycle of release (roughly 6 weeks), we should think about 
> 2.5.0.
> 
> I'm volunteer to tackle this release.
> 
> I'm proposing the following items:
> 
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you think we
> will be ready to try a release with Gradle ?
> 
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be interesting to 
> have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, 
> I
> will start a thread about that.
> 
> Thoughts ?
> 
> Regards
> JB
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-06-01 Thread Jasper Wang
Hi JB and team,

Very excited to hear that the release process of python SDK 2.5 has
started. Can’t wait to use it for streaming on Dataflow.

Just a silly question though - how long the release process typically takes?

Thx in advance.

Jasper

On Thu, 31 May 2018 at 11:14 pm, Jean-Baptiste Onofré 
wrote:

> Yes I confirm: I already checked that last week. Thanks for the double
> check !
>
> Regards
> JB
> Le 31 mai 2018, à 15:13, Etienne Chauchot  a écrit:
>>
>> Hi,
>> I did some tests on the maven artifacts produced by the gradle build:
>>
>> I published maven artifacts to local maven repo using :
>>
>>  ./gradlew publishToMavenLocal -PisRelease --no-parallel -x test
>>
>> then used beam samples project (maven based) and did a
>>
>> mvn dependency:tree
>>
>> => transitive dependencies of all beam related artifacts are well resolved
>>
>> Le jeudi 31 mai 2018 à 14:43 +0200, Jean-Baptiste Onofré a écrit :
>>
>> Agree, I gonna start the release process tonight (my time).
>>
>> Regards
>> JB
>> Le 31 mai 2018, à 14:29, Kenneth Knowles < k...@google.com> a écrit:
>>
>> Yea - the branch should be cut before trying to finish the burndown.
>>
>> Kenn
>>
>> On Thu, May 31, 2018 at 2:09 AM Robert Bradshaw < rober...@google.com>
>> wrote:
>>
>> I think it makes sense to cut the release and get the ball rolling, and
>> iff the  ParquetIO/S3 issue turns out to be simple, we cherry-pick,
>> otherwise we add a note.
>>
>> On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré < j...@nanthrax.net>
>> wrote:
>>
>> Hi,
>>
>> Regarding RabbitMqIO, Eugene provided new feedback last night that I
>> would like to implement. However, it's not a release blocker, so I will
>> move forward with 2.5.0 release without RabbitMqIO  (I will include in
>> 2.6.0).
>>
>> Regarding ParquetIO, I tested HDFS successfully as well (I had an issue
>> on my namenode). S3 is important, but I think we can just add a note in
>> the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
>>
>> So, please, let me know if I can start the release process today (I
>> would like to  move forward asap).
>>
>> Thanks,
>> Regards
>> JB
>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Jean-Baptiste Onofré
Yes I confirm: I already checked that last week. Thanks for the double check !

Regards
JB

Le 31 mai 2018 à 15:13, à 15:13, Etienne Chauchot  a 
écrit:
>Hi,
>I did some tests on the maven artifacts produced by the gradle build:
>I published maven artifacts to local maven repo using :
> ./gradlew publishToMavenLocal -PisRelease --no-parallel -x test
>then used beam samples project (maven based) and did a
>mvn dependency:tree
>=> transitive dependencies of all beam related artifacts are well
>resolved
>
>Le jeudi 31 mai 2018 à 14:43 +0200, Jean-Baptiste Onofré a écrit :
>> Agree, I gonna start the release process tonight (my time).
>>
>>
>> Regards
>>
>> JB
>>
>> Le 31 mai 2018, à 14:29, Kenneth Knowles  a écrit:
>> > Yea - the branch should be cut before trying to finish the
>burndown.
>> > Kenn
>> > On Thu, May 31, 2018 at 2:09 AM Robert Bradshaw
> wrote:
>> > > I think it makes sense to cut the release and get the ball
>rolling, and iff the ParquetIO/S3 issue turns out to be
>> > > simple, we cherry-pick, otherwise we add a note.
>> > > On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré
> wrote:
>> > > > Hi,
>> > > >
>> > > >
>> > > >
>> > > > Regarding RabbitMqIO, Eugene provided new feedback last night
>that I
>> > > >
>> > > > would like to implement. However, it's not a release blocker,
>so I will
>> > > >
>> > > > move forward with 2.5.0 release without RabbitMqIO  (I will
>include in
>> > > >
>> > > > 2.6.0).
>> > > >
>> > > >
>> > > >
>> > > > Regarding ParquetIO, I tested HDFS successfully as well (I had
>an issue
>> > > >
>> > > > on my namenode). S3 is important, but I think we can just add a
>note in
>> > > >
>> > > > the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
>> > > >
>> > > >
>> > > >
>> > > > So, please, let me know if I can start the release process
>today (I
>> > > >
>> > > > would like to  move forward asap).
>> > > >
>> > > >
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Regards
>> > > >
>> > > > JB
>> > > >
>> > > >


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Etienne Chauchot
Hi,
I did some tests on the maven artifacts produced by the gradle build:
I published maven artifacts to local maven repo using :
 ./gradlew publishToMavenLocal -PisRelease --no-parallel -x test
then used beam samples project (maven based) and did a
mvn dependency:tree
=> transitive dependencies of all beam related artifacts are well resolved

Le jeudi 31 mai 2018 à 14:43 +0200, Jean-Baptiste Onofré a écrit :
> Agree, I gonna start the release process tonight (my time).
> 
> 
> Regards
> 
> JB
> 
> Le 31 mai 2018, à 14:29, Kenneth Knowles  a écrit:
> > Yea - the branch should be cut before trying to finish the burndown.
> > Kenn
> > On Thu, May 31, 2018 at 2:09 AM Robert Bradshaw  wrote:
> > > I think it makes sense to cut the release and get the ball rolling, and 
> > > iff the ParquetIO/S3 issue turns out to be
> > > simple, we cherry-pick, otherwise we add a note. 
> > > On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré  
> > > wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > 
> > > > Regarding RabbitMqIO, Eugene provided new feedback last night that I
> > > > 
> > > > would like to implement. However, it's not a release blocker, so I will
> > > > 
> > > > move forward with 2.5.0 release without RabbitMqIO  (I will include in
> > > > 
> > > > 2.6.0).
> > > > 
> > > > 
> > > > 
> > > > Regarding ParquetIO, I tested HDFS successfully as well (I had an issue
> > > > 
> > > > on my namenode). S3 is important, but I think we can just add a note in
> > > > 
> > > > the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
> > > > 
> > > > 
> > > > 
> > > > So, please, let me know if I can start the release process today (I
> > > > 
> > > > would like to  move forward asap).
> > > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > Regards
> > > > 
> > > > JB
> > > > 
> > > > 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Jean-Baptiste Onofré
Agree, I gonna start the release process tonight (my time).

Regards
JB

Le 31 mai 2018 à 14:29, à 14:29, Kenneth Knowles  a écrit:
>Yea - the branch should be cut before trying to finish the burndown.
>
>Kenn
>
>On Thu, May 31, 2018 at 2:09 AM Robert Bradshaw 
>wrote:
>
>> I think it makes sense to cut the release and get the ball rolling,
>and
>> iff the ParquetIO/S3 issue turns out to be simple, we cherry-pick,
>> otherwise we add a note.
>>
>> On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré
>
>> wrote:
>>
>>> Hi,
>>>
>>> Regarding RabbitMqIO, Eugene provided new feedback last night that I
>>> would like to implement. However, it's not a release blocker, so I
>will
>>> move forward with 2.5.0 release without RabbitMqIO  (I will include
>in
>>> 2.6.0).
>>>
>>> Regarding ParquetIO, I tested HDFS successfully as well (I had an
>issue
>>> on my namenode). S3 is important, but I think we can just add a note
>in
>>> the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
>>>
>>> So, please, let me know if I can start the release process today (I
>>> would like to  move forward asap).
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Kenneth Knowles
Yea - the branch should be cut before trying to finish the burndown.

Kenn

On Thu, May 31, 2018 at 2:09 AM Robert Bradshaw  wrote:

> I think it makes sense to cut the release and get the ball rolling, and
> iff the ParquetIO/S3 issue turns out to be simple, we cherry-pick,
> otherwise we add a note.
>
> On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré 
> wrote:
>
>> Hi,
>>
>> Regarding RabbitMqIO, Eugene provided new feedback last night that I
>> would like to implement. However, it's not a release blocker, so I will
>> move forward with 2.5.0 release without RabbitMqIO  (I will include in
>> 2.6.0).
>>
>> Regarding ParquetIO, I tested HDFS successfully as well (I had an issue
>> on my namenode). S3 is important, but I think we can just add a note in
>> the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
>>
>> So, please, let me know if I can start the release process today (I
>> would like to  move forward asap).
>>
>> Thanks,
>> Regards
>> JB
>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Robert Bradshaw
I think it makes sense to cut the release and get the ball rolling, and iff
the ParquetIO/S3 issue turns out to be simple, we cherry-pick, otherwise we
add a note.

On Thu, May 31, 2018 at 1:56 AM Jean-Baptiste Onofré 
wrote:

> Hi,
>
> Regarding RabbitMqIO, Eugene provided new feedback last night that I
> would like to implement. However, it's not a release blocker, so I will
> move forward with 2.5.0 release without RabbitMqIO  (I will include in
> 2.6.0).
>
> Regarding ParquetIO, I tested HDFS successfully as well (I had an issue
> on my namenode). S3 is important, but I think we can just add a note in
> the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?
>
> So, please, let me know if I can start the release process today (I
> would like to  move forward asap).
>
> Thanks,
> Regards
> JB
>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Jean-Baptiste Onofré
Hi,

Regarding RabbitMqIO, Eugene provided new feedback last night that I
would like to implement. However, it's not a release blocker, so I will
move forward with 2.5.0 release without RabbitMqIO  (I will include in
2.6.0).

Regarding ParquetIO, I tested HDFS successfully as well (I had an issue
on my namenode). S3 is important, but I think we can just add a note in
the RELEASE NOTE  and move forward with 2.5.0. Thoughts ?

So, please, let me know if I can start the release process today (I
would like to  move forward asap).

Thanks,
Regards
JB

On 31/05/2018 10:52, Alexey Romanenko wrote:
> *ParquetIO on S3* - I may confirm that it works only for “Write”, “Read"
> throws an exception:
> /org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.io.IOException: can not read class
> org.apache.parquet.format.FileMetaData: java.io.IOException: Attempted
> read on closed stream./
> Any ideas about the cause of this would be very welcomed.
> 
> *ParquetIO on HDFS* - works fine for me too (Write and Read).
> 
> WBR,
> Alexey
> 
>> On 31 May 2018, at 00:46, Łukasz Gajowy > > wrote:
>>
>> Regarding ParquetIO on S3: I am investigating the issue. It seems that
>> it never worked on s3 (I didn't expect that). Currently, I'm trying to
>> understand why it behaves differently than on other filesystems (HDFS,
>> local). Any help appreciated.
>>
>> Regarding ParquetIO on HDFS: I was able to run it on my machine
>> successfully. I also created a PR with HDFS Performance test for
>> Parquet (and it is passing
>> too): https://github.com/apache/beam/pull/5520. Hope this will be helpful!
>>
>> Best regards, 
>> Łukasz 
>>
>>
>>
>> 2018-05-31 0:41 GMT+02:00 Robert Bradshaw > >:
>>
>> On Wed, May 30, 2018 at 12:59 PM Ahmet Altay > > wrote:
>>
>> Thank you JB.
>>
>> For clarification, are you referring to the following items:
>> - RabbitMqIO - https://github.com/apache/beam/pull/1729
>> 
>> -  ParquetIO on HDFS/S3
>> - https://issues.apache.org/jira/browse/BEAM-4421
>> 
>>
>> If the above mapping is correct, could we separate addition of
>> new feature from addressing blocking issues? I would propose
>> that we do not block the release for the former one and fix
>> the latter one before the release.
>>
>> On Tue, May 29, 2018 at 10:26 PM, Jean-Baptiste Onofré
>> mailto:j...@nanthrax.net>> wrote:
>>
>> Hi,
>>
>> I would like to merge RabbitMqIO (we are doing the final
>> touches) and we
>> have an issue about ParquetIO on HDFS/S3 that I would like to
>> investigate with the team.
>>
>>
>> Do you know who is currently investigating the ParquetIO
>> issue? Do you need help with that?
>>
>>
>> Do we know if this is a regression, or has it never worked? 
>>  
>>
>> I plan to start the release process asap, hopefully later
>> today.
>>
>>
>> That would be great. A lot has happened since the last release [1]
>> and we've had a pretty good cadence so far in 2018 so it'd be nice
>> to get this out in to the hands of our users. And thanks for
>> volunteering to do the release! 
>>
>> - Robert
>>
>>
>> [1] https://github.com/apache/beam/compare/release-2.4.0...master
>> 
>>
>>
>>  
>>
>>
>> Regards
>> JB
>>
>> On 29/05/2018 23:00, Ahmet Altay wrote:
>> > Thank you JB for the update. Could we start the release 
>> process now? Is
>> > there anyway I could help with moving the release forward?
>> > 
>> > On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik > 
>> > >> wrote:
>> > 
>> >     Thanks for the update JB.
>> > 
>> >     Kenn, we have the post commit integration tests which run 
>> against
>> >     shaded artifacts like validates runner. We also have the 
>> nightly
>> >     snapshot and its verification run which validates the 
>> nightly
>> >     snapshot with DirectRunner / Dataflow / Apex / Spark / 
>> Flink for
>> >     WordCount and DirectRunner / Dataflow for the mobile 
>> gaming examples.
>> > 
>> >     I'm not sure about the IOs and whether the perfkit 
>> benchmark work
>> >     adequately covers them.
>> > 
>> > 
>> >     On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
>> >     mailto:j...@nanthrax.net>
>> >> wrote:
>> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-31 Thread Alexey Romanenko
ParquetIO on S3 - I may confirm that it works only for “Write”, “Read" throws 
an exception:
org.apache.beam.sdk.Pipeline$PipelineExecutionException: java.io.IOException: 
can not read class org.apache.parquet.format.FileMetaData: java.io.IOException: 
Attempted read on closed stream.
Any ideas about the cause of this would be very welcomed.

ParquetIO on HDFS - works fine for me too (Write and Read).

WBR,
Alexey

> On 31 May 2018, at 00:46, Łukasz Gajowy  wrote:
> 
> Regarding ParquetIO on S3: I am investigating the issue. It seems that it 
> never worked on s3 (I didn't expect that). Currently, I'm trying to 
> understand why it behaves differently than on other filesystems (HDFS, 
> local). Any help appreciated.
> 
> Regarding ParquetIO on HDFS: I was able to run it on my machine successfully. 
> I also created a PR with HDFS Performance test for Parquet (and it is passing 
> too): https://github.com/apache/beam/pull/5520 
> . Hope this will be helpful!
> 
> Best regards, 
> Łukasz 
> 
> 
> 
> 2018-05-31 0:41 GMT+02:00 Robert Bradshaw  >:
> On Wed, May 30, 2018 at 12:59 PM Ahmet Altay  > wrote:
> Thank you JB.
> 
> For clarification, are you referring to the following items:
> - RabbitMqIO - https://github.com/apache/beam/pull/1729 
> 
> -  ParquetIO on HDFS/S3 - https://issues.apache.org/jira/browse/BEAM-4421 
> 
> 
> If the above mapping is correct, could we separate addition of new feature 
> from addressing blocking issues? I would propose that we do not block the 
> release for the former one and fix the latter one before the release.
> 
> On Tue, May 29, 2018 at 10:26 PM, Jean-Baptiste Onofré  > wrote:
> Hi,
> 
> I would like to merge RabbitMqIO (we are doing the final touches) and we
> have an issue about ParquetIO on HDFS/S3 that I would like to
> investigate with the team.
> 
> Do you know who is currently investigating the ParquetIO issue? Do you need 
> help with that?
> 
> Do we know if this is a regression, or has it never worked? 
>  
> I plan to start the release process asap, hopefully later today.
> 
> That would be great. A lot has happened since the last release [1] and we've 
> had a pretty good cadence so far in 2018 so it'd be nice to get this out in 
> to the hands of our users. And thanks for volunteering to do the release! 
> 
> - Robert
> 
> 
> [1] https://github.com/apache/beam/compare/release-2.4.0...master 
> 
> 
> 
>  
> 
> Regards
> JB
> 
> On 29/05/2018 23:00, Ahmet Altay wrote:
> > Thank you JB for the update. Could we start the release process now? Is
> > there anyway I could help with moving the release forward?
> > 
> > On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik  > 
> > >> wrote:
> > 
> > Thanks for the update JB.
> > 
> > Kenn, we have the post commit integration tests which run against
> > shaded artifacts like validates runner. We also have the nightly
> > snapshot and its verification run which validates the nightly
> > snapshot with DirectRunner / Dataflow / Apex / Spark / Flink for
> > WordCount and DirectRunner / Dataflow for the mobile gaming examples.
> > 
> > I'm not sure about the IOs and whether the perfkit benchmark work
> > adequately covers them.
> > 
> > 
> > On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>  > >> wrote:
> > 
> > Hi Luke,
> > 
> > I tested the following build:
> > 
> > ./gradlew publishToMavenLocal -PisRelease --no-parallel
> > 
> > The artifacts are present in my .m2/repository.
> > 
> > For instance, I can see:
> > 
> > .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
> > total 16256
> >  beam-sdks-java-core-2.5.0.jar
> >  beam-sdks-java-core-2.5.0.jar.asc
> >  beam-sdks-java-core-2.5.0-javadoc.jar
> >  beam-sdks-java-core-2.5.0-javadoc.jar.asc
> >  beam-sdks-java-core-2.5.0.pom
> >  beam-sdks-java-core-2.5.0.pom.asc
> >  beam-sdks-java-core-2.5.0-sources.jar
> >  beam-sdks-java-core-2.5.0-sources.jar.asc
> >  beam-sdks-java-core-2.5.0-tests.jar
> >  beam-sdks-java-core-2.5.0-tests.jar.asc
> >  beam-sdks-java-core-2.5.0-test-sources.jar
> >  beam-sdks-java-core-2.5.0-test-sources.jar.asc
> > 
> > 1. The signatures are OK:
> > 
> > gpg --verify beam-sdks-java-core-2.5.0.jar.asc
> > beam-sdks-java-core-2.5.0.jar
> > gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
> > gpg:using RSA key
> > 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
> >   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-30 Thread Łukasz Gajowy
Regarding ParquetIO on S3: I am investigating the issue. It seems that it
never worked on s3 (I didn't expect that). Currently, I'm trying to
understand why it behaves differently than on other filesystems (HDFS,
local). Any help appreciated.

Regarding ParquetIO on HDFS: I was able to run it on my machine
successfully. I also created a PR with HDFS Performance test for Parquet
(and it is passing too): https://github.com/apache/beam/pull/5520. Hope
this will be helpful!

Best regards,
Łukasz



2018-05-31 0:41 GMT+02:00 Robert Bradshaw :

> On Wed, May 30, 2018 at 12:59 PM Ahmet Altay  wrote:
>
>> Thank you JB.
>>
>> For clarification, are you referring to the following items:
>> - RabbitMqIO - https://github.com/apache/beam/pull/1729
>> -  ParquetIO on HDFS/S3 - https://issues.apache.org/jira/browse/BEAM-4421
>>
>> If the above mapping is correct, could we separate addition of new
>> feature from addressing blocking issues? I would propose that we do not
>> block the release for the former one and fix the latter one before the
>> release.
>>
>> On Tue, May 29, 2018 at 10:26 PM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to merge RabbitMqIO (we are doing the final touches) and we
>>> have an issue about ParquetIO on HDFS/S3 that I would like to
>>> investigate with the team.
>>>
>>
>> Do you know who is currently investigating the ParquetIO issue? Do you
>> need help with that?
>>
>
> Do we know if this is a regression, or has it never worked?
>
>
>> I plan to start the release process asap, hopefully later today.
>>>
>>
> That would be great. A lot has happened since the last release [1] and
> we've had a pretty good cadence so far in 2018 so it'd be nice to get this
> out in to the hands of our users. And thanks for volunteering to do the
> release!
>
> - Robert
>
>
> [1] https://github.com/apache/beam/compare/release-2.4.0...master
>
>
>
>
>>
>>> Regards
>>> JB
>>>
>>> On 29/05/2018 23:00, Ahmet Altay wrote:
>>> > Thank you JB for the update. Could we start the release process now? Is
>>> > there anyway I could help with moving the release forward?
>>> >
>>> > On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik >> > > wrote:
>>> >
>>> > Thanks for the update JB.
>>> >
>>> > Kenn, we have the post commit integration tests which run against
>>> > shaded artifacts like validates runner. We also have the nightly
>>> > snapshot and its verification run which validates the nightly
>>> > snapshot with DirectRunner / Dataflow / Apex / Spark / Flink for
>>> > WordCount and DirectRunner / Dataflow for the mobile gaming
>>> examples.
>>> >
>>> > I'm not sure about the IOs and whether the perfkit benchmark work
>>> > adequately covers them.
>>> >
>>> >
>>> > On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
>>> > mailto:j...@nanthrax.net>> wrote:
>>> >
>>> > Hi Luke,
>>> >
>>> > I tested the following build:
>>> >
>>> > ./gradlew publishToMavenLocal -PisRelease --no-parallel
>>> >
>>> > The artifacts are present in my .m2/repository.
>>> >
>>> > For instance, I can see:
>>> >
>>> > .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls
>>> -l
>>> > total 16256
>>> >  beam-sdks-java-core-2.5.0.jar
>>> >  beam-sdks-java-core-2.5.0.jar.asc
>>> >  beam-sdks-java-core-2.5.0-javadoc.jar
>>> >  beam-sdks-java-core-2.5.0-javadoc.jar.asc
>>> >  beam-sdks-java-core-2.5.0.pom
>>> >  beam-sdks-java-core-2.5.0.pom.asc
>>> >  beam-sdks-java-core-2.5.0-sources.jar
>>> >  beam-sdks-java-core-2.5.0-sources.jar.asc
>>> >  beam-sdks-java-core-2.5.0-tests.jar
>>> >  beam-sdks-java-core-2.5.0-tests.jar.asc
>>> >  beam-sdks-java-core-2.5.0-test-sources.jar
>>> >  beam-sdks-java-core-2.5.0-test-sources.jar.asc
>>> >
>>> > 1. The signatures are OK:
>>> >
>>> > gpg --verify beam-sdks-java-core-2.5.0.jar.asc
>>> > beam-sdks-java-core-2.5.0.jar
>>> > gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
>>> > gpg:using RSA key
>>> > 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
>>> > gpg: Good signature from "Jean-Baptiste Onofré
>>> > mailto:jbono...@apache.org>>"
>>> > [unknown]
>>> >
>>> > 2. The pom looks correct to me but it's not optimal because
>>> >
>>> > 2.1. There's no parent definition, so each pom duplicate the
>>> same
>>> > configurations (like scm, license, etc)
>>> > 2.2. There's no Maven plugin configuration, even if it's not
>>> > used for
>>> > the build, other tools can parse and use plugin configuration
>>> > (like the
>>> > source/target version, etc).
>>> >
>>> > So, even if it's not optimal, the pom looks overall good.
>>> >
>>> > I think it makes sense to move forward on the release as it is
>>> > right now.
>>> >

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-30 Thread Robert Bradshaw
On Wed, May 30, 2018 at 12:59 PM Ahmet Altay  wrote:

> Thank you JB.
>
> For clarification, are you referring to the following items:
> - RabbitMqIO - https://github.com/apache/beam/pull/1729
> -  ParquetIO on HDFS/S3 - https://issues.apache.org/jira/browse/BEAM-4421
>
> If the above mapping is correct, could we separate addition of new feature
> from addressing blocking issues? I would propose that we do not block the
> release for the former one and fix the latter one before the release.
>
> On Tue, May 29, 2018 at 10:26 PM, Jean-Baptiste Onofré 
> wrote:
>
>> Hi,
>>
>> I would like to merge RabbitMqIO (we are doing the final touches) and we
>> have an issue about ParquetIO on HDFS/S3 that I would like to
>> investigate with the team.
>>
>
> Do you know who is currently investigating the ParquetIO issue? Do you
> need help with that?
>

Do we know if this is a regression, or has it never worked?


> I plan to start the release process asap, hopefully later today.
>>
>
That would be great. A lot has happened since the last release [1] and
we've had a pretty good cadence so far in 2018 so it'd be nice to get this
out in to the hands of our users. And thanks for volunteering to do the
release!

- Robert


[1] https://github.com/apache/beam/compare/release-2.4.0...master




>
>> Regards
>> JB
>>
>> On 29/05/2018 23:00, Ahmet Altay wrote:
>> > Thank you JB for the update. Could we start the release process now? Is
>> > there anyway I could help with moving the release forward?
>> >
>> > On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik > > > wrote:
>> >
>> > Thanks for the update JB.
>> >
>> > Kenn, we have the post commit integration tests which run against
>> > shaded artifacts like validates runner. We also have the nightly
>> > snapshot and its verification run which validates the nightly
>> > snapshot with DirectRunner / Dataflow / Apex / Spark / Flink for
>> > WordCount and DirectRunner / Dataflow for the mobile gaming
>> examples.
>> >
>> > I'm not sure about the IOs and whether the perfkit benchmark work
>> > adequately covers them.
>> >
>> >
>> > On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>> wrote:
>> >
>> > Hi Luke,
>> >
>> > I tested the following build:
>> >
>> > ./gradlew publishToMavenLocal -PisRelease --no-parallel
>> >
>> > The artifacts are present in my .m2/repository.
>> >
>> > For instance, I can see:
>> >
>> > .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
>> > total 16256
>> >  beam-sdks-java-core-2.5.0.jar
>> >  beam-sdks-java-core-2.5.0.jar.asc
>> >  beam-sdks-java-core-2.5.0-javadoc.jar
>> >  beam-sdks-java-core-2.5.0-javadoc.jar.asc
>> >  beam-sdks-java-core-2.5.0.pom
>> >  beam-sdks-java-core-2.5.0.pom.asc
>> >  beam-sdks-java-core-2.5.0-sources.jar
>> >  beam-sdks-java-core-2.5.0-sources.jar.asc
>> >  beam-sdks-java-core-2.5.0-tests.jar
>> >  beam-sdks-java-core-2.5.0-tests.jar.asc
>> >  beam-sdks-java-core-2.5.0-test-sources.jar
>> >  beam-sdks-java-core-2.5.0-test-sources.jar.asc
>> >
>> > 1. The signatures are OK:
>> >
>> > gpg --verify beam-sdks-java-core-2.5.0.jar.asc
>> > beam-sdks-java-core-2.5.0.jar
>> > gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
>> > gpg:using RSA key
>> > 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
>> > gpg: Good signature from "Jean-Baptiste Onofré
>> > mailto:jbono...@apache.org>>"
>> > [unknown]
>> >
>> > 2. The pom looks correct to me but it's not optimal because
>> >
>> > 2.1. There's no parent definition, so each pom duplicate the
>> same
>> > configurations (like scm, license, etc)
>> > 2.2. There's no Maven plugin configuration, even if it's not
>> > used for
>> > the build, other tools can parse and use plugin configuration
>> > (like the
>> > source/target version, etc).
>> >
>> > So, even if it's not optimal, the pom looks overall good.
>> >
>> > I think it makes sense to move forward on the release as it is
>> > right now.
>> >
>> > If there's no objection, I will start the release process
>> during the
>> > week end.
>> >
>> > By the way, it would be good to verify that the Maven build is
>> still
>> > working. Ismaël and I fixed new issues on the Maven build.
>> > At some point, after the 2.5.0 release, we have to state to
>> > remove the
>> > Maven build (after a vote ;)).
>> >
>> > Thanks,
>> > Regards
>> > JB
>> >
>> >
>> > On 25/05/2018 01:34, Lukasz Cwik wrote:
>> > > The license inclusion issue that was brought up on the thread
>> > has been
>> > > resolved 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-30 Thread Ahmet Altay
Thank you JB.

For clarification, are you referring to the following items:
- RabbitMqIO - https://github.com/apache/beam/pull/1729
-  ParquetIO on HDFS/S3 - https://issues.apache.org/jira/browse/BEAM-4421

If the above mapping is correct, could we separate addition of new feature
from addressing blocking issues? I would propose that we do not block the
release for the former one and fix the latter one before the release.

On Tue, May 29, 2018 at 10:26 PM, Jean-Baptiste Onofré 
wrote:

> Hi,
>
> I would like to merge RabbitMqIO (we are doing the final touches) and we
> have an issue about ParquetIO on HDFS/S3 that I would like to
> investigate with the team.
>

Do you know who is currently investigating the ParquetIO issue? Do you need
help with that?


>
> I plan to start the release process asap, hopefully later today.
>
> Regards
> JB
>
> On 29/05/2018 23:00, Ahmet Altay wrote:
> > Thank you JB for the update. Could we start the release process now? Is
> > there anyway I could help with moving the release forward?
> >
> > On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik  > > wrote:
> >
> > Thanks for the update JB.
> >
> > Kenn, we have the post commit integration tests which run against
> > shaded artifacts like validates runner. We also have the nightly
> > snapshot and its verification run which validates the nightly
> > snapshot with DirectRunner / Dataflow / Apex / Spark / Flink for
> > WordCount and DirectRunner / Dataflow for the mobile gaming examples.
> >
> > I'm not sure about the IOs and whether the perfkit benchmark work
> > adequately covers them.
> >
> >
> > On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>> wrote:
> >
> > Hi Luke,
> >
> > I tested the following build:
> >
> > ./gradlew publishToMavenLocal -PisRelease --no-parallel
> >
> > The artifacts are present in my .m2/repository.
> >
> > For instance, I can see:
> >
> > .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
> > total 16256
> >  beam-sdks-java-core-2.5.0.jar
> >  beam-sdks-java-core-2.5.0.jar.asc
> >  beam-sdks-java-core-2.5.0-javadoc.jar
> >  beam-sdks-java-core-2.5.0-javadoc.jar.asc
> >  beam-sdks-java-core-2.5.0.pom
> >  beam-sdks-java-core-2.5.0.pom.asc
> >  beam-sdks-java-core-2.5.0-sources.jar
> >  beam-sdks-java-core-2.5.0-sources.jar.asc
> >  beam-sdks-java-core-2.5.0-tests.jar
> >  beam-sdks-java-core-2.5.0-tests.jar.asc
> >  beam-sdks-java-core-2.5.0-test-sources.jar
> >  beam-sdks-java-core-2.5.0-test-sources.jar.asc
> >
> > 1. The signatures are OK:
> >
> > gpg --verify beam-sdks-java-core-2.5.0.jar.asc
> > beam-sdks-java-core-2.5.0.jar
> > gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
> > gpg:using RSA key
> > 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
> > gpg: Good signature from "Jean-Baptiste Onofré
> > mailto:jbono...@apache.org>>"
> > [unknown]
> >
> > 2. The pom looks correct to me but it's not optimal because
> >
> > 2.1. There's no parent definition, so each pom duplicate the same
> > configurations (like scm, license, etc)
> > 2.2. There's no Maven plugin configuration, even if it's not
> > used for
> > the build, other tools can parse and use plugin configuration
> > (like the
> > source/target version, etc).
> >
> > So, even if it's not optimal, the pom looks overall good.
> >
> > I think it makes sense to move forward on the release as it is
> > right now.
> >
> > If there's no objection, I will start the release process during
> the
> > week end.
> >
> > By the way, it would be good to verify that the Maven build is
> still
> > working. Ismaël and I fixed new issues on the Maven build.
> > At some point, after the 2.5.0 release, we have to state to
> > remove the
> > Maven build (after a vote ;)).
> >
> > Thanks,
> > Regards
> > JB
> >
> >
> > On 25/05/2018 01:34, Lukasz Cwik wrote:
> > > The license inclusion issue that was brought up on the thread
> > has been
> > > resolved https://issues.apache.org/jira/browse/BEAM-4393
> > .
> > >
> > > JB, you find any other release related issues?
> > >
> > > On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  > 
> > > >> wrote:
> > >
> > > I believe JB is referring
> > > to https://issues.apache.org/jira/browse/BEAM-4060
> > 
> > >
> > >

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-29 Thread Jean-Baptiste Onofré
Hi,

I would like to merge RabbitMqIO (we are doing the final touches) and we
have an issue about ParquetIO on HDFS/S3 that I would like to
investigate with the team.

I plan to start the release process asap, hopefully later today.

Regards
JB

On 29/05/2018 23:00, Ahmet Altay wrote:
> Thank you JB for the update. Could we start the release process now? Is
> there anyway I could help with moving the release forward?
> 
> On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik  > wrote:
> 
> Thanks for the update JB.
> 
> Kenn, we have the post commit integration tests which run against
> shaded artifacts like validates runner. We also have the nightly
> snapshot and its verification run which validates the nightly
> snapshot with DirectRunner / Dataflow / Apex / Spark / Flink for
> WordCount and DirectRunner / Dataflow for the mobile gaming examples.
> 
> I'm not sure about the IOs and whether the perfkit benchmark work
> adequately covers them.
> 
> 
> On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>> wrote:
> 
> Hi Luke,
> 
> I tested the following build:
> 
> ./gradlew publishToMavenLocal -PisRelease --no-parallel
> 
> The artifacts are present in my .m2/repository.
> 
> For instance, I can see:
> 
> .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
> total 16256
>  beam-sdks-java-core-2.5.0.jar
>  beam-sdks-java-core-2.5.0.jar.asc
>  beam-sdks-java-core-2.5.0-javadoc.jar
>  beam-sdks-java-core-2.5.0-javadoc.jar.asc
>  beam-sdks-java-core-2.5.0.pom
>  beam-sdks-java-core-2.5.0.pom.asc
>  beam-sdks-java-core-2.5.0-sources.jar
>  beam-sdks-java-core-2.5.0-sources.jar.asc
>  beam-sdks-java-core-2.5.0-tests.jar
>  beam-sdks-java-core-2.5.0-tests.jar.asc
>  beam-sdks-java-core-2.5.0-test-sources.jar
>  beam-sdks-java-core-2.5.0-test-sources.jar.asc
> 
> 1. The signatures are OK:
> 
> gpg --verify beam-sdks-java-core-2.5.0.jar.asc
> beam-sdks-java-core-2.5.0.jar
> gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
> gpg:                using RSA key
> 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
> gpg: Good signature from "Jean-Baptiste Onofré
> mailto:jbono...@apache.org>>"
> [unknown]
> 
> 2. The pom looks correct to me but it's not optimal because
> 
> 2.1. There's no parent definition, so each pom duplicate the same
> configurations (like scm, license, etc)
> 2.2. There's no Maven plugin configuration, even if it's not
> used for
> the build, other tools can parse and use plugin configuration
> (like the
> source/target version, etc).
> 
> So, even if it's not optimal, the pom looks overall good.
> 
> I think it makes sense to move forward on the release as it is
> right now.
> 
> If there's no objection, I will start the release process during the
> week end.
> 
> By the way, it would be good to verify that the Maven build is still
> working. Ismaël and I fixed new issues on the Maven build.
> At some point, after the 2.5.0 release, we have to state to
> remove the
> Maven build (after a vote ;)).
> 
> Thanks,
> Regards
> JB
> 
> 
> On 25/05/2018 01:34, Lukasz Cwik wrote:
> > The license inclusion issue that was brought up on the thread
> has been
> > resolved https://issues.apache.org/jira/browse/BEAM-4393
> .
> >
> > JB, you find any other release related issues?
> >
> > On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  
> > >> wrote:
> >
> >     I believe JB is referring
> >     to https://issues.apache.org/jira/browse/BEAM-4060
> 
> >
> >     On Fri, May 18, 2018 at 10:16 AM Scott Wegner
> mailto:sweg...@google.com>
> >     >>
> wrote:
> >
> >         J.B., can you give any context on what metadata is
> missing? Is
> >         there a JIRA?
> >
> >         On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré
> >         mailto:j...@nanthrax.net>
> >> wrote:
> >
> >             Hi,
> >
> >             The build was OK  yesterday but the maven-metadata
> is still
> >             missing.
> >
> >             That's the point to  fix before being able to move
> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-29 Thread Ahmet Altay
Thank you JB for the update. Could we start the release process now? Is
there anyway I could help with moving the release forward?

On Fri, May 25, 2018 at 8:19 AM, Lukasz Cwik  wrote:

> Thanks for the update JB.
>
> Kenn, we have the post commit integration tests which run against shaded
> artifacts like validates runner. We also have the nightly snapshot and its
> verification run which validates the nightly snapshot with DirectRunner /
> Dataflow / Apex / Spark / Flink for WordCount and DirectRunner / Dataflow
> for the mobile gaming examples.
>
> I'm not sure about the IOs and whether the perfkit benchmark work
> adequately covers them.
>
>
> On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré 
> wrote:
>
>> Hi Luke,
>>
>> I tested the following build:
>>
>> ./gradlew publishToMavenLocal -PisRelease --no-parallel
>>
>> The artifacts are present in my .m2/repository.
>>
>> For instance, I can see:
>>
>> .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
>> total 16256
>>  beam-sdks-java-core-2.5.0.jar
>>  beam-sdks-java-core-2.5.0.jar.asc
>>  beam-sdks-java-core-2.5.0-javadoc.jar
>>  beam-sdks-java-core-2.5.0-javadoc.jar.asc
>>  beam-sdks-java-core-2.5.0.pom
>>  beam-sdks-java-core-2.5.0.pom.asc
>>  beam-sdks-java-core-2.5.0-sources.jar
>>  beam-sdks-java-core-2.5.0-sources.jar.asc
>>  beam-sdks-java-core-2.5.0-tests.jar
>>  beam-sdks-java-core-2.5.0-tests.jar.asc
>>  beam-sdks-java-core-2.5.0-test-sources.jar
>>  beam-sdks-java-core-2.5.0-test-sources.jar.asc
>>
>> 1. The signatures are OK:
>>
>> gpg --verify beam-sdks-java-core-2.5.0.jar.asc
>> beam-sdks-java-core-2.5.0.jar
>> gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
>> gpg:using RSA key 1AA8CF92D409A73393D0B736BFF2EE
>> 42C8282E76
>> gpg: Good signature from "Jean-Baptiste Onofré "
>> [unknown]
>>
>> 2. The pom looks correct to me but it's not optimal because
>>
>> 2.1. There's no parent definition, so each pom duplicate the same
>> configurations (like scm, license, etc)
>> 2.2. There's no Maven plugin configuration, even if it's not used for
>> the build, other tools can parse and use plugin configuration (like the
>> source/target version, etc).
>>
>> So, even if it's not optimal, the pom looks overall good.
>>
>> I think it makes sense to move forward on the release as it is right now.
>>
>> If there's no objection, I will start the release process during the
>> week end.
>>
>> By the way, it would be good to verify that the Maven build is still
>> working. Ismaël and I fixed new issues on the Maven build.
>> At some point, after the 2.5.0 release, we have to state to remove the
>> Maven build (after a vote ;)).
>>
>> Thanks,
>> Regards
>> JB
>>
>>
>> On 25/05/2018 01:34, Lukasz Cwik wrote:
>> > The license inclusion issue that was brought up on the thread has been
>> > resolved https://issues.apache.org/jira/browse/BEAM-4393.
>> >
>> > JB, you find any other release related issues?
>> >
>> > On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik > > > wrote:
>> >
>> > I believe JB is referring
>> > to https://issues.apache.org/jira/browse/BEAM-4060
>> >
>> > On Fri, May 18, 2018 at 10:16 AM Scott Wegner > > > wrote:
>> >
>> > J.B., can you give any context on what metadata is missing? Is
>> > there a JIRA?
>> >
>> > On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>> wrote:
>> >
>> > Hi,
>> >
>> > The build was OK  yesterday but the maven-metadata is still
>> > missing.
>> >
>> > That's the point to  fix before being able to move forward
>> > on  the release.
>> >
>> > I  gonna tackle this later today.
>> >
>> > Regards
>> > JB
>> >
>> > On 05/18/2018 02:41 AM, Ahmet Altay wrote:
>> > > Hi JB and all,
>> > >
>> > > I wanted to follow up on my previous email. The python
>> > streaming issue I
>> > > mentioned is resolved and removed from the blocker list.
>> > Blocker list is empty
>> > > now. You can go ahead with the release branch cut when you
>> > are ready.
>> > >
>> > > Thank you,
>> > > Ahmet
>> > >
>> > >
>> > > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>
>> > > >> wrote:
>> > >
>> > > Hi guys,
>> > >
>> > > just to let you know that the build fully passed on my
>> > box.
>> > >
>> > > I'm testing the artifacts right now.
>> > >
>> > > Regards
>> > > JB
>> > >
>> > > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> >

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-25 Thread Lukasz Cwik
Thanks for the update JB.

Kenn, we have the post commit integration tests which run against shaded
artifacts like validates runner. We also have the nightly snapshot and its
verification run which validates the nightly snapshot with DirectRunner /
Dataflow / Apex / Spark / Flink for WordCount and DirectRunner / Dataflow
for the mobile gaming examples.

I'm not sure about the IOs and whether the perfkit benchmark work
adequately covers them.


On Fri, May 25, 2018 at 1:28 AM Jean-Baptiste Onofré 
wrote:

> Hi Luke,
>
> I tested the following build:
>
> ./gradlew publishToMavenLocal -PisRelease --no-parallel
>
> The artifacts are present in my .m2/repository.
>
> For instance, I can see:
>
> .m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
> total 16256
>  beam-sdks-java-core-2.5.0.jar
>  beam-sdks-java-core-2.5.0.jar.asc
>  beam-sdks-java-core-2.5.0-javadoc.jar
>  beam-sdks-java-core-2.5.0-javadoc.jar.asc
>  beam-sdks-java-core-2.5.0.pom
>  beam-sdks-java-core-2.5.0.pom.asc
>  beam-sdks-java-core-2.5.0-sources.jar
>  beam-sdks-java-core-2.5.0-sources.jar.asc
>  beam-sdks-java-core-2.5.0-tests.jar
>  beam-sdks-java-core-2.5.0-tests.jar.asc
>  beam-sdks-java-core-2.5.0-test-sources.jar
>  beam-sdks-java-core-2.5.0-test-sources.jar.asc
>
> 1. The signatures are OK:
>
> gpg --verify beam-sdks-java-core-2.5.0.jar.asc
> beam-sdks-java-core-2.5.0.jar
> gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
> gpg:using RSA key 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
> gpg: Good signature from "Jean-Baptiste Onofré "
> [unknown]
>
> 2. The pom looks correct to me but it's not optimal because
>
> 2.1. There's no parent definition, so each pom duplicate the same
> configurations (like scm, license, etc)
> 2.2. There's no Maven plugin configuration, even if it's not used for
> the build, other tools can parse and use plugin configuration (like the
> source/target version, etc).
>
> So, even if it's not optimal, the pom looks overall good.
>
> I think it makes sense to move forward on the release as it is right now.
>
> If there's no objection, I will start the release process during the
> week end.
>
> By the way, it would be good to verify that the Maven build is still
> working. Ismaël and I fixed new issues on the Maven build.
> At some point, after the 2.5.0 release, we have to state to remove the
> Maven build (after a vote ;)).
>
> Thanks,
> Regards
> JB
>
>
> On 25/05/2018 01:34, Lukasz Cwik wrote:
> > The license inclusion issue that was brought up on the thread has been
> > resolved https://issues.apache.org/jira/browse/BEAM-4393.
> >
> > JB, you find any other release related issues?
> >
> > On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  > > wrote:
> >
> > I believe JB is referring
> > to https://issues.apache.org/jira/browse/BEAM-4060
> >
> > On Fri, May 18, 2018 at 10:16 AM Scott Wegner  > > wrote:
> >
> > J.B., can you give any context on what metadata is missing? Is
> > there a JIRA?
> >
> > On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré
> > > wrote:
> >
> > Hi,
> >
> > The build was OK  yesterday but the maven-metadata is still
> > missing.
> >
> > That's the point to  fix before being able to move forward
> > on  the release.
> >
> > I  gonna tackle this later today.
> >
> > Regards
> > JB
> >
> > On 05/18/2018 02:41 AM, Ahmet Altay wrote:
> > > Hi JB and all,
> > >
> > > I wanted to follow up on my previous email. The python
> > streaming issue I
> > > mentioned is resolved and removed from the blocker list.
> > Blocker list is empty
> > > now. You can go ahead with the release branch cut when you
> > are ready.
> > >
> > > Thank you,
> > > Ahmet
> > >
> > >
> > > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré
> > 
> > > >> wrote:
> > >
> > > Hi guys,
> > >
> > > just to let you know that the build fully passed on my
> > box.
> > >
> > > I'm testing the artifacts right now.
> > >
> > > Regards
> > > JB
> > >
> > > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > >
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-25 Thread Jean-Baptiste Onofré
Hi Luke,

I tested the following build:

./gradlew publishToMavenLocal -PisRelease --no-parallel

The artifacts are present in my .m2/repository.

For instance, I can see:

.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0$ ls -l
total 16256
 beam-sdks-java-core-2.5.0.jar
 beam-sdks-java-core-2.5.0.jar.asc
 beam-sdks-java-core-2.5.0-javadoc.jar
 beam-sdks-java-core-2.5.0-javadoc.jar.asc
 beam-sdks-java-core-2.5.0.pom
 beam-sdks-java-core-2.5.0.pom.asc
 beam-sdks-java-core-2.5.0-sources.jar
 beam-sdks-java-core-2.5.0-sources.jar.asc
 beam-sdks-java-core-2.5.0-tests.jar
 beam-sdks-java-core-2.5.0-tests.jar.asc
 beam-sdks-java-core-2.5.0-test-sources.jar
 beam-sdks-java-core-2.5.0-test-sources.jar.asc

1. The signatures are OK:

gpg --verify beam-sdks-java-core-2.5.0.jar.asc beam-sdks-java-core-2.5.0.jar
gpg: Signature made jeu. 24 mai 2018 16:55:11 CEST
gpg:using RSA key 1AA8CF92D409A73393D0B736BFF2EE42C8282E76
gpg: Good signature from "Jean-Baptiste Onofré "
[unknown]

2. The pom looks correct to me but it's not optimal because

2.1. There's no parent definition, so each pom duplicate the same
configurations (like scm, license, etc)
2.2. There's no Maven plugin configuration, even if it's not used for
the build, other tools can parse and use plugin configuration (like the
source/target version, etc).

So, even if it's not optimal, the pom looks overall good.

I think it makes sense to move forward on the release as it is right now.

If there's no objection, I will start the release process during the
week end.

By the way, it would be good to verify that the Maven build is still
working. Ismaël and I fixed new issues on the Maven build.
At some point, after the 2.5.0 release, we have to state to remove the
Maven build (after a vote ;)).

Thanks,
Regards
JB


On 25/05/2018 01:34, Lukasz Cwik wrote:
> The license inclusion issue that was brought up on the thread has been
> resolved https://issues.apache.org/jira/browse/BEAM-4393.
> 
> JB, you find any other release related issues?
> 
> On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  > wrote:
> 
> I believe JB is referring
> to https://issues.apache.org/jira/browse/BEAM-4060
> 
> On Fri, May 18, 2018 at 10:16 AM Scott Wegner  > wrote:
> 
> J.B., can you give any context on what metadata is missing? Is
> there a JIRA?
> 
> On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré
> > wrote:
> 
> Hi,
> 
> The build was OK  yesterday but the maven-metadata is still
> missing.
> 
> That's the point to  fix before being able to move forward
> on  the release.
> 
> I  gonna tackle this later today.
> 
> Regards
> JB
> 
> On 05/18/2018 02:41 AM, Ahmet Altay wrote:
> > Hi JB and all,
> >
> > I wanted to follow up on my previous email. The python
> streaming issue I
> > mentioned is resolved and removed from the blocker list.
> Blocker list is empty
> > now. You can go ahead with the release branch cut when you
> are ready.
> >
> > Thank you,
> > Ahmet
> >
> >
> > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré
> 
> > >> wrote:
> >
> >     Hi guys,
> >
> >     just to let you know that the build fully passed on my
> box.
> >
> >     I'm testing the artifacts right now.
> >
> >     Regards
> >     JB
> >
> >     On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> >
> >         Hi guys,
> >
> >         Apache Beam 2.4.0 has been released on March 20th.
> >
> >         According to our cycle of release (roughly 6
> weeks), we should think
> >         about 2.5.0.
> >
> >         I'm volunteer to tackle this release.
> >
> >         I'm proposing the following items:
> >
> >         1. We start the Jira triage now, up to Tuesday
> >         2. I would like to cut the release on Tuesday
> night (Europe time)
> >         2bis. I think it's wiser to still use Maven for
> this release. Do you
> >         think we
> >         will be ready to try a release with Gradle ?
> >
> >         After this release, I would like a discussion about:
> >         1. 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-24 Thread Kenneth Knowles
Do we have adequate integration test coverage of the actual released
artifacts that https://issues.apache.org/jira/browse/BEAM-4402 is not a
blocker?

On Thu, May 24, 2018 at 4:35 PM Lukasz Cwik  wrote:

> The license inclusion issue that was brought up on the thread has been
> resolved https://issues.apache.org/jira/browse/BEAM-4393.
>
> JB, you find any other release related issues?
>
> On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  wrote:
>
>> I believe JB is referring to
>> https://issues.apache.org/jira/browse/BEAM-4060
>>
>> On Fri, May 18, 2018 at 10:16 AM Scott Wegner  wrote:
>>
>>> J.B., can you give any context on what metadata is missing? Is there a
>>> JIRA?
>>>
>>> On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré 
>>> wrote:
>>>
 Hi,

 The build was OK  yesterday but the maven-metadata is still missing.

 That's the point to  fix before being able to move forward on  the
 release.

 I  gonna tackle this later today.

 Regards
 JB

 On 05/18/2018 02:41 AM, Ahmet Altay wrote:
 > Hi JB and all,
 >
 > I wanted to follow up on my previous email. The python streaming
 issue I
 > mentioned is resolved and removed from the blocker list. Blocker list
 is empty
 > now. You can go ahead with the release branch cut when you are ready.
 >
 > Thank you,
 > Ahmet
 >
 >
 > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré <
 j...@nanthrax.net
 > > wrote:
 >
 > Hi guys,
 >
 > just to let you know that the build fully passed on my box.
 >
 > I'm testing the artifacts right now.
 >
 > Regards
 > JB
 >
 > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
 >
 > Hi guys,
 >
 > Apache Beam 2.4.0 has been released on March 20th.
 >
 > According to our cycle of release (roughly 6 weeks), we
 should think
 > about 2.5.0.
 >
 > I'm volunteer to tackle this release.
 >
 > I'm proposing the following items:
 >
 > 1. We start the Jira triage now, up to Tuesday
 > 2. I would like to cut the release on Tuesday night (Europe
 time)
 > 2bis. I think it's wiser to still use Maven for this release.
 Do you
 > think we
 > will be ready to try a release with Gradle ?
 >
 > After this release, I would like a discussion about:
 > 1. Gradle release (if we release 2.5.0 with Maven)
 > 2. Isolate release cycle per Beam part. I think it would be
 interesting
 > to have
 > different release cycle: SDKs, DSLs, Runners, IOs. That's
 another
 > discussion, I
 > will start a thread about that.
 >
 > Thoughts ?
 >
 > Regards
 > JB
 >
 >

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

>>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-24 Thread Lukasz Cwik
The license inclusion issue that was brought up on the thread has been
resolved https://issues.apache.org/jira/browse/BEAM-4393.

JB, you find any other release related issues?

On Fri, May 18, 2018 at 10:33 AM Lukasz Cwik  wrote:

> I believe JB is referring to
> https://issues.apache.org/jira/browse/BEAM-4060
>
> On Fri, May 18, 2018 at 10:16 AM Scott Wegner  wrote:
>
>> J.B., can you give any context on what metadata is missing? Is there a
>> JIRA?
>>
>> On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi,
>>>
>>> The build was OK  yesterday but the maven-metadata is still missing.
>>>
>>> That's the point to  fix before being able to move forward on  the
>>> release.
>>>
>>> I  gonna tackle this later today.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/18/2018 02:41 AM, Ahmet Altay wrote:
>>> > Hi JB and all,
>>> >
>>> > I wanted to follow up on my previous email. The python streaming issue
>>> I
>>> > mentioned is resolved and removed from the blocker list. Blocker list
>>> is empty
>>> > now. You can go ahead with the release branch cut when you are ready.
>>> >
>>> > Thank you,
>>> > Ahmet
>>> >
>>> >
>>> > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré >> > > wrote:
>>> >
>>> > Hi guys,
>>> >
>>> > just to let you know that the build fully passed on my box.
>>> >
>>> > I'm testing the artifacts right now.
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> >
>>> > Hi guys,
>>> >
>>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >
>>> > According to our cycle of release (roughly 6 weeks), we should
>>> think
>>> > about 2.5.0.
>>> >
>>> > I'm volunteer to tackle this release.
>>> >
>>> > I'm proposing the following items:
>>> >
>>> > 1. We start the Jira triage now, up to Tuesday
>>> > 2. I would like to cut the release on Tuesday night (Europe
>>> time)
>>> > 2bis. I think it's wiser to still use Maven for this release.
>>> Do you
>>> > think we
>>> > will be ready to try a release with Gradle ?
>>> >
>>> > After this release, I would like a discussion about:
>>> > 1. Gradle release (if we release 2.5.0 with Maven)
>>> > 2. Isolate release cycle per Beam part. I think it would be
>>> interesting
>>> > to have
>>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
>>> another
>>> > discussion, I
>>> > will start a thread about that.
>>> >
>>> > Thoughts ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>> >
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-18 Thread Lukasz Cwik
I believe JB is referring to https://issues.apache.org/jira/browse/BEAM-4060

On Fri, May 18, 2018 at 10:16 AM Scott Wegner  wrote:

> J.B., can you give any context on what metadata is missing? Is there a
> JIRA?
>
> On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré 
> wrote:
>
>> Hi,
>>
>> The build was OK  yesterday but the maven-metadata is still missing.
>>
>> That's the point to  fix before being able to move forward on  the
>> release.
>>
>> I  gonna tackle this later today.
>>
>> Regards
>> JB
>>
>> On 05/18/2018 02:41 AM, Ahmet Altay wrote:
>> > Hi JB and all,
>> >
>> > I wanted to follow up on my previous email. The python streaming issue I
>> > mentioned is resolved and removed from the blocker list. Blocker list
>> is empty
>> > now. You can go ahead with the release branch cut when you are ready.
>> >
>> > Thank you,
>> > Ahmet
>> >
>> >
>> > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré > > > wrote:
>> >
>> > Hi guys,
>> >
>> > just to let you know that the build fully passed on my box.
>> >
>> > I'm testing the artifacts right now.
>> >
>> > Regards
>> > JB
>> >
>> > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> >
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should
>> think
>> > about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe
>> time)
>> > 2bis. I think it's wiser to still use Maven for this release.
>> Do you
>> > think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be
>> interesting
>> > to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's
>> another
>> > discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-18 Thread Scott Wegner
J.B., can you give any context on what metadata is missing? Is there a JIRA?

On Thu, May 17, 2018 at 9:30 PM Jean-Baptiste Onofré 
wrote:

> Hi,
>
> The build was OK  yesterday but the maven-metadata is still missing.
>
> That's the point to  fix before being able to move forward on  the release.
>
> I  gonna tackle this later today.
>
> Regards
> JB
>
> On 05/18/2018 02:41 AM, Ahmet Altay wrote:
> > Hi JB and all,
> >
> > I wanted to follow up on my previous email. The python streaming issue I
> > mentioned is resolved and removed from the blocker list. Blocker list is
> empty
> > now. You can go ahead with the release branch cut when you are ready.
> >
> > Thank you,
> > Ahmet
> >
> >
> > On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré  > > wrote:
> >
> > Hi guys,
> >
> > just to let you know that the build fully passed on my box.
> >
> > I'm testing the artifacts right now.
> >
> > Regards
> > JB
> >
> > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> >
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should
> think
> > about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do
> you
> > think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be
> interesting
> > to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> > discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-17 Thread Jean-Baptiste Onofré
Hi,

The build was OK  yesterday but the maven-metadata is still missing.

That's the point to  fix before being able to move forward on  the release.

I  gonna tackle this later today.

Regards
JB

On 05/18/2018 02:41 AM, Ahmet Altay wrote:
> Hi JB and all,
> 
> I wanted to follow up on my previous email. The python streaming issue I
> mentioned is resolved and removed from the blocker list. Blocker list is empty
> now. You can go ahead with the release branch cut when you are ready.
> 
> Thank you,
> Ahmet
> 
> 
> On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré  > wrote:
> 
> Hi guys,
> 
> just to let you know that the build fully passed on my box.
> 
> I'm testing the artifacts right now.
> 
> Regards
> JB
> 
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> 
> Hi guys,
> 
> Apache Beam 2.4.0 has been released on March 20th.
> 
> According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> 
> I'm volunteer to tackle this release.
> 
> I'm proposing the following items:
> 
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> will be ready to try a release with Gradle ?
> 
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be 
> interesting
> to have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> will start a thread about that.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-17 Thread Ahmet Altay
On Thu, May 17, 2018 at 6:08 PM, Kenneth Knowles  wrote:

> In case you didn't see the other thread, Andrew just discovered a problem
> in SQL's jar build. It may be a release blocker.
>

I missed Andrew's email. I only looked at the release blocking list. If it
might be a release blocker, could you please add it to the list?


>
> Just an FYI. Since the fix is likely small fixes to build file it seems ok
> to cut the branch and cherry pick.
>
> Kenn
>
> On Thu, May 17, 2018, 17:41 Ahmet Altay  wrote:
>
>> Hi JB and all,
>>
>> I wanted to follow up on my previous email. The python streaming issue I
>> mentioned is resolved and removed from the blocker list. Blocker list is
>> empty now. You can go ahead with the release branch cut when you are ready.
>>
>> Thank you,
>> Ahmet
>>
>>
>> On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi guys,
>>>
>>> just to let you know that the build fully passed on my box.
>>>
>>> I'm testing the artifacts right now.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>>
 Hi guys,

 Apache Beam 2.4.0 has been released on March 20th.

 According to our cycle of release (roughly 6 weeks), we should think
 about 2.5.0.

 I'm volunteer to tackle this release.

 I'm proposing the following items:

 1. We start the Jira triage now, up to Tuesday
 2. I would like to cut the release on Tuesday night (Europe time)
 2bis. I think it's wiser to still use Maven for this release. Do you
 think we
 will be ready to try a release with Gradle ?

 After this release, I would like a discussion about:
 1. Gradle release (if we release 2.5.0 with Maven)
 2. Isolate release cycle per Beam part. I think it would be interesting
 to have
 different release cycle: SDKs, DSLs, Runners, IOs. That's another
 discussion, I
 will start a thread about that.

 Thoughts ?

 Regards
 JB


>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-17 Thread Kenneth Knowles
In case you didn't see the other thread, Andrew just discovered a problem
in SQL's jar build. It may be a release blocker.

Just an FYI. Since the fix is likely small fixes to build file it seems ok
to cut the branch and cherry pick.

Kenn

On Thu, May 17, 2018, 17:41 Ahmet Altay  wrote:

> Hi JB and all,
>
> I wanted to follow up on my previous email. The python streaming issue I
> mentioned is resolved and removed from the blocker list. Blocker list is
> empty now. You can go ahead with the release branch cut when you are ready.
>
> Thank you,
> Ahmet
>
>
> On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré 
> wrote:
>
>> Hi guys,
>>
>> just to let you know that the build fully passed on my box.
>>
>> I'm testing the artifacts right now.
>>
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>
>>> Hi guys,
>>>
>>> Apache Beam 2.4.0 has been released on March 20th.
>>>
>>> According to our cycle of release (roughly 6 weeks), we should think
>>> about 2.5.0.
>>>
>>> I'm volunteer to tackle this release.
>>>
>>> I'm proposing the following items:
>>>
>>> 1. We start the Jira triage now, up to Tuesday
>>> 2. I would like to cut the release on Tuesday night (Europe time)
>>> 2bis. I think it's wiser to still use Maven for this release. Do you
>>> think we
>>> will be ready to try a release with Gradle ?
>>>
>>> After this release, I would like a discussion about:
>>> 1. Gradle release (if we release 2.5.0 with Maven)
>>> 2. Isolate release cycle per Beam part. I think it would be interesting
>>> to have
>>> different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>> discussion, I
>>> will start a thread about that.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-17 Thread Ahmet Altay
Hi JB and all,

I wanted to follow up on my previous email. The python streaming issue I
mentioned is resolved and removed from the blocker list. Blocker list is
empty now. You can go ahead with the release branch cut when you are ready.

Thank you,
Ahmet


On Sun, May 13, 2018 at 8:43 AM, Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> just to let you know that the build fully passed on my box.
>
> I'm testing the artifacts right now.
>
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>
>> Hi guys,
>>
>> Apache Beam 2.4.0 has been released on March 20th.
>>
>> According to our cycle of release (roughly 6 weeks), we should think
>> about 2.5.0.
>>
>> I'm volunteer to tackle this release.
>>
>> I'm proposing the following items:
>>
>> 1. We start the Jira triage now, up to Tuesday
>> 2. I would like to cut the release on Tuesday night (Europe time)
>> 2bis. I think it's wiser to still use Maven for this release. Do you
>> think we
>> will be ready to try a release with Gradle ?
>>
>> After this release, I would like a discussion about:
>> 1. Gradle release (if we release 2.5.0 with Maven)
>> 2. Isolate release cycle per Beam part. I think it would be interesting
>> to have
>> different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> discussion, I
>> will start a thread about that.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-13 Thread Jean-Baptiste Onofré

Hi guys,

just to let you know that the build fully passed on my box.

I'm testing the artifacts right now.

Regards
JB

On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:

Hi guys,

Apache Beam 2.4.0 has been released on March 20th.

According to our cycle of release (roughly 6 weeks), we should think about 
2.5.0.

I'm volunteer to tackle this release.

I'm proposing the following items:

1. We start the Jira triage now, up to Tuesday
2. I would like to cut the release on Tuesday night (Europe time)
2bis. I think it's wiser to still use Maven for this release. Do you think we
will be ready to try a release with Gradle ?

After this release, I would like a discussion about:
1. Gradle release (if we release 2.5.0 with Maven)
2. Isolate release cycle per Beam part. I think it would be interesting to have
different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, I
will start a thread about that.

Thoughts ?

Regards
JB



Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-08 Thread Scott Wegner
Thanks for the update JB. Please open JIRA's for any Gradle release
blockers with as much context as you have.

On Tue, May 8, 2018 at 12:32 PM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> new update on the 2.5.0 release preparation.
>
> I tested the artifacts published by gradle (using gradlew
> publishToLocalMaven) in "my" beam-samples (which still use the mvn).
>
> Unfortuntaly beam-samples project doesn't build as some artifacts seem
> to miss in the local repository.
> I'm also checking the generated maven coordinates generated (metadata,
> etc), and I'm not sure they are complete.
>
> On the other hand, I have build failure using gradle on python SDK (I
> think it's an environment issue due to the update to Ubuntu 18.04, I'm
> checking the python version, lint, ...) and go SDK (investigating).
>
> So, I need more time to completely review artifacts and build.
>
> I keep you posted.
>
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-08 Thread Jean-Baptiste Onofré

Hi guys,

new update on the 2.5.0 release preparation.

I tested the artifacts published by gradle (using gradlew 
publishToLocalMaven) in "my" beam-samples (which still use the mvn).


Unfortuntaly beam-samples project doesn't build as some artifacts seem 
to miss in the local repository.
I'm also checking the generated maven coordinates generated (metadata, 
etc), and I'm not sure they are complete.


On the other hand, I have build failure using gradle on python SDK (I 
think it's an environment issue due to the update to Ubuntu 18.04, I'm 
checking the python version, lint, ...) and go SDK (investigating).


So, I need more time to completely review artifacts and build.

I keep you posted.

Regards
JB

On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:

Hi guys,

Apache Beam 2.4.0 has been released on March 20th.

According to our cycle of release (roughly 6 weeks), we should think about 
2.5.0.

I'm volunteer to tackle this release.

I'm proposing the following items:

1. We start the Jira triage now, up to Tuesday
2. I would like to cut the release on Tuesday night (Europe time)
2bis. I think it's wiser to still use Maven for this release. Do you think we
will be ready to try a release with Gradle ?

After this release, I would like a discussion about:
1. Gradle release (if we release 2.5.0 with Maven)
2. Isolate release cycle per Beam part. I think it would be interesting to have
different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, I
will start a thread about that.

Thoughts ?

Regards
JB



Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-04 Thread Andrew Pilloud
Spanner is also broken, and post commits are failing. I've added the issue
as a blocker. https://issues.apache.org/jira/browse/BEAM-4229

Andrew

On Fri, May 4, 2018 at 1:24 PM Charles Chen  wrote:

> I have added https://issues.apache.org/jira/browse/BEAM-4236 as a blocker.
>
> On Fri, May 4, 2018 at 1:19 PM Ahmet Altay  wrote:
>
>> Hi JB,
>>
>> We found an issue related to using side inputs in streaming mode using
>> python SDK. Charles is currently trying to find the root cause. Would you
>> be able to give him some additional time to investigate the issue?
>>
>> Charles, do you have a JIRA issue on the blocker list?
>>
>> Thank you everyone for understanding.
>>
>> Ahmet
>>
>> On Fri, May 4, 2018 at 8:52 AM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi
>>>
>>> I have couple of PRs I would like to include. I would like also to take
>>> the weekend for new builds and tests.
>>>
>>> If it works for everyone I propose to start the release process Tuesday.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>> Le 4 mai 2018, à 17:49, Scott Wegner  a écrit:

 Hi JB, any idea when you will begin the release? Boyuan has a couple
 Python PRs [1] [2] that are ready to merge, but we'd like to wait until
 after the release branch is cut in case there is some performance
 regression.

 [1] https://github.com/apache/beam/pull/4741
 [2] https://github.com/apache/beam/pull/4925

 On Tue, May 1, 2018 at 9:25 AM Scott Wegner  wrote:

> Sounds good, thanks J.B. Feel free to ping if you need anything.
>
> On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré 
> wrote:
>
>> That's a good idea ! I think using Slack to ping/ask is a good way as
>> it's async.
>>
>> Regards
>> JB
>>
>> On 05/01/2018 06:51 AM, Reuven Lax wrote:
>> > I think it makes sense to have someone who hadn't done the Gradle
>> migration to
>> > run the release. However would it make sense for someone who did
>> work on the
>> > migration to partner with you JB? There may be issues that are
>> simply due to
>> > things that were not documented well. In that case the partner can
>> quickly help
>> > resolve, and can then be the one who makes sure that the
>> documentation is updated.
>> >
>> > Reuven
>> >
>> > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré <
>> j...@nanthrax.net
>> > > wrote:
>> >
>> > Hi Scott,
>> >
>> > Thanks for the update. The Gradle build crashed on my machine
>> (not related to
>> > Gradle). I launched a new one.
>> >
>> > I'm volunteer to cut the release: I think I know Gradle
>> decently, and even if I
>> > didn't work on the gradle "migration" during the last two
>> weeks, I think it's
>> > actually better: I have an "external" view on the latest
>> changes.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>> > On 05/01/2018 02:05 AM, Scott Wegner wrote:
>> > > Welcome back JB!
>> > >
>> > > I just sent a separate update about Gradle [1]-- the build
>> migration is
>> > complete
>> > > and the release documentation has been updated.
>> > >
>> > > I recommend we produce the 2.5.0 release using Gradle. Having
>> a successful
>> > > release should be the final validation before declaring the
>> Gradle migration
>> > > complete. So the sooner we can have a Gradle release, the
>> sooner we can
>> > get back
>> > > to a single build system :)
>> > >
>> > > If it would be helpful, I suggest that somebody who's been
>> working on the
>> > Gradle
>> > > migration to manage the 2.5.0 release. That way if we
>> encounter any issues
>> > from
>> > > the build system, they should have sufficient expertise to
>> fix it.
>> > >
>> > >
>> > [1]
>> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>>
>> > >
>> > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > 
>> > > >>
>> wrote:
>> > >
>> > >
>> > >
>> > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré" <
>> j...@nanthrax.net
>> > 
>> > > >> a
>> écrit :
>> > >
>> > > Hi guys,
>> > >
>> > > now that I'm back from vacations, I bring back 2.5.0
>> release on
>> > the 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-04 Thread Ahmet Altay
Hi JB,

We found an issue related to using side inputs in streaming mode using
python SDK. Charles is currently trying to find the root cause. Would you
be able to give him some additional time to investigate the issue?

Charles, do you have a JIRA issue on the blocker list?

Thank you everyone for understanding.

Ahmet

On Fri, May 4, 2018 at 8:52 AM, Jean-Baptiste Onofré 
wrote:

> Hi
>
> I have couple of PRs I would like to include. I would like also to take
> the weekend for new builds and tests.
>
> If it works for everyone I propose to start the release process Tuesday.
>
> Thoughts ?
>
> Regards
> JB
> Le 4 mai 2018, à 17:49, Scott Wegner  a écrit:
>>
>> Hi JB, any idea when you will begin the release? Boyuan has a couple
>> Python PRs [1] [2] that are ready to merge, but we'd like to wait until
>> after the release branch is cut in case there is some performance
>> regression.
>>
>> [1] https://github.com/apache/beam/pull/4741
>> [2] https://github.com/apache/beam/pull/4925
>>
>> On Tue, May 1, 2018 at 9:25 AM Scott Wegner  wrote:
>>
>>> Sounds good, thanks J.B. Feel free to ping if you need anything.
>>>
>>> On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré 
>>> wrote:
>>>
 That's a good idea ! I think using Slack to ping/ask is a good way as
 it's async.

 Regards
 JB

 On 05/01/2018 06:51 AM, Reuven Lax wrote:
 > I think it makes sense to have someone who hadn't done the Gradle
 migration to
 > run the release. However would it make sense for someone who did work
 on the
 > migration to partner with you JB? There may be issues that are simply
 due to
 > things that were not documented well. In that case the partner can
 quickly help
 > resolve, and can then be the one who makes sure that the
 documentation is updated.
 >
 > Reuven
 >
 > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré  > wrote:
 >
 > Hi Scott,
 >
 > Thanks for the update. The Gradle build crashed on my machine
 (not related to
 > Gradle). I launched a new one.
 >
 > I'm volunteer to cut the release: I think I know Gradle decently,
 and even if I
 > didn't work on the gradle "migration" during the last two weeks,
 I think it's
 > actually better: I have an "external" view on the latest changes.
 >
 > Thoughts ?
 >
 > Regards
 > JB
 >
 > On 05/01/2018 02:05 AM, Scott Wegner wrote:
 > > Welcome back JB!
 > >
 > > I just sent a separate update about Gradle [1]-- the build
 migration is
 > complete
 > > and the release documentation has been updated.
 > >
 > > I recommend we produce the 2.5.0 release using Gradle. Having a
 successful
 > > release should be the final validation before declaring the
 Gradle migration
 > > complete. So the sooner we can have a Gradle release, the
 sooner we can
 > get back
 > > to a single build system :)
 > >
 > > If it would be helpful, I suggest that somebody who's been
 working on the
 > Gradle
 > > migration to manage the 2.5.0 release. That way if we encounter
 any issues
 > from
 > > the build system, they should have sufficient expertise to fix
 it.
 > >
 > >
 > [1] https://lists.apache.org/thread.html/
 e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%
 3Cdev.beam.apache.org%3E
 > >
 > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
 rmannibu...@gmail.com
 > 
 > > >>
 wrote:
 > >
 > >
 > >
 > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré" <
 j...@nanthrax.net
 > 
 > > >> a
 écrit :
 > >
 > > Hi guys,
 > >
 > > now that I'm back from vacations, I bring back 2.5.0
 release on
 > the table ;)
 > >
 > > This is also related to the current status of build
 (Maven/Gradle).
 > >
 > > FYI, I gonna start the Jira triage tomorrow and I
 launched couple of
 > > build on my
 > > machine (both Maven and Gradle) to get an update on the
 current
 > status.
 > >
 > > Please, let me know if you have an opinion about Gradle
 vs Maven
 > for the
 > > release.
 > >
 > >
 > > Produced artifacts are still too different to use gradle
 IMHO. Jira were
 > > 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-04 Thread Charles Chen
I have added https://issues.apache.org/jira/browse/BEAM-4236 as a blocker.

On Fri, May 4, 2018 at 1:19 PM Ahmet Altay  wrote:

> Hi JB,
>
> We found an issue related to using side inputs in streaming mode using
> python SDK. Charles is currently trying to find the root cause. Would you
> be able to give him some additional time to investigate the issue?
>
> Charles, do you have a JIRA issue on the blocker list?
>
> Thank you everyone for understanding.
>
> Ahmet
>
> On Fri, May 4, 2018 at 8:52 AM, Jean-Baptiste Onofré 
> wrote:
>
>> Hi
>>
>> I have couple of PRs I would like to include. I would like also to take
>> the weekend for new builds and tests.
>>
>> If it works for everyone I propose to start the release process Tuesday.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>> Le 4 mai 2018, à 17:49, Scott Wegner  a écrit:
>>>
>>> Hi JB, any idea when you will begin the release? Boyuan has a couple
>>> Python PRs [1] [2] that are ready to merge, but we'd like to wait until
>>> after the release branch is cut in case there is some performance
>>> regression.
>>>
>>> [1] https://github.com/apache/beam/pull/4741
>>> [2] https://github.com/apache/beam/pull/4925
>>>
>>> On Tue, May 1, 2018 at 9:25 AM Scott Wegner  wrote:
>>>
 Sounds good, thanks J.B. Feel free to ping if you need anything.

 On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré 
 wrote:

> That's a good idea ! I think using Slack to ping/ask is a good way as
> it's async.
>
> Regards
> JB
>
> On 05/01/2018 06:51 AM, Reuven Lax wrote:
> > I think it makes sense to have someone who hadn't done the Gradle
> migration to
> > run the release. However would it make sense for someone who did
> work on the
> > migration to partner with you JB? There may be issues that are
> simply due to
> > things that were not documented well. In that case the partner can
> quickly help
> > resolve, and can then be the one who makes sure that the
> documentation is updated.
> >
> > Reuven
> >
> > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré <
> j...@nanthrax.net
> > > wrote:
> >
> > Hi Scott,
> >
> > Thanks for the update. The Gradle build crashed on my machine
> (not related to
> > Gradle). I launched a new one.
> >
> > I'm volunteer to cut the release: I think I know Gradle
> decently, and even if I
> > didn't work on the gradle "migration" during the last two weeks,
> I think it's
> > actually better: I have an "external" view on the latest changes.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On 05/01/2018 02:05 AM, Scott Wegner wrote:
> > > Welcome back JB!
> > >
> > > I just sent a separate update about Gradle [1]-- the build
> migration is
> > complete
> > > and the release documentation has been updated.
> > >
> > > I recommend we produce the 2.5.0 release using Gradle. Having
> a successful
> > > release should be the final validation before declaring the
> Gradle migration
> > > complete. So the sooner we can have a Gradle release, the
> sooner we can
> > get back
> > > to a single build system :)
> > >
> > > If it would be helpful, I suggest that somebody who's been
> working on the
> > Gradle
> > > migration to manage the 2.5.0 release. That way if we
> encounter any issues
> > from
> > > the build system, they should have sufficient expertise to fix
> it.
> > >
> > >
> > [1]
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>
> > >
> > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > 
> > > >>
> wrote:
> > >
> > >
> > >
> > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré" <
> j...@nanthrax.net
> > 
> > > >> a
> écrit :
> > >
> > > Hi guys,
> > >
> > > now that I'm back from vacations, I bring back 2.5.0
> release on
> > the table ;)
> > >
> > > This is also related to the current status of build
> (Maven/Gradle).
> > >
> > > FYI, I gonna start the Jira triage tomorrow and I
> launched couple of
> > > build on my
> > > machine (both Maven and Gradle) to get an update on
> the current
> >   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-04 Thread Jean-Baptiste Onofré
Hi

I have couple of PRs I would like to include. I would like also to take the 
weekend for new builds and tests.

If it works for everyone I propose to start the release process Tuesday.

Thoughts ?

Regards
JB

Le 4 mai 2018 à 17:49, à 17:49, Scott Wegner  a écrit:
>Hi JB, any idea when you will begin the release? Boyuan has a couple
>Python
>PRs [1] [2] that are ready to merge, but we'd like to wait until after
>the
>release branch is cut in case there is some performance regression.
>
>[1] https://github.com/apache/beam/pull/4741
>[2] https://github.com/apache/beam/pull/4925
>
>On Tue, May 1, 2018 at 9:25 AM Scott Wegner  wrote:
>
>> Sounds good, thanks J.B. Feel free to ping if you need anything.
>>
>> On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré
>
>> wrote:
>>
>>> That's a good idea ! I think using Slack to ping/ask is a good way
>as
>>> it's async.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/01/2018 06:51 AM, Reuven Lax wrote:
>>> > I think it makes sense to have someone who hadn't done the Gradle
>>> migration to
>>> > run the release. However would it make sense for someone who did
>work
>>> on the
>>> > migration to partner with you JB? There may be issues that are
>simply
>>> due to
>>> > things that were not documented well. In that case the partner can
>>> quickly help
>>> > resolve, and can then be the one who makes sure that the
>documentation
>>> is updated.
>>> >
>>> > Reuven
>>> >
>>> > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré
>>> > > wrote:
>>> >
>>> > Hi Scott,
>>> >
>>> > Thanks for the update. The Gradle build crashed on my machine
>(not
>>> related to
>>> > Gradle). I launched a new one.
>>> >
>>> > I'm volunteer to cut the release: I think I know Gradle
>decently,
>>> and even if I
>>> > didn't work on the gradle "migration" during the last two
>weeks, I
>>> think it's
>>> > actually better: I have an "external" view on the latest
>changes.
>>> >
>>> > Thoughts ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 05/01/2018 02:05 AM, Scott Wegner wrote:
>>> > > Welcome back JB!
>>> > >
>>> > > I just sent a separate update about Gradle [1]-- the build
>>> migration is
>>> > complete
>>> > > and the release documentation has been updated.
>>> > >
>>> > > I recommend we produce the 2.5.0 release using Gradle.
>Having a
>>> successful
>>> > > release should be the final validation before declaring the
>>> Gradle migration
>>> > > complete. So the sooner we can have a Gradle release, the
>sooner
>>> we can
>>> > get back
>>> > > to a single build system :)
>>> > >
>>> > > If it would be helpful, I suggest that somebody who's been
>>> working on the
>>> > Gradle
>>> > > migration to manage the 2.5.0 release. That way if we
>encounter
>>> any issues
>>> > from
>>> > > the build system, they should have sufficient expertise to
>fix it.
>>> > >
>>> > >
>>> > [1]
>>>
>https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>>>
>>> > >
>>> > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com
>>> > 
>>> > > >>
>>> wrote:
>>> > >
>>> > >
>>> > >
>>> > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré" <
>>> j...@nanthrax.net
>>> > 
>>> > > >> a
>écrit :
>>> > >
>>> > > Hi guys,
>>> > >
>>> > > now that I'm back from vacations, I bring back 2.5.0
>>> release on
>>> > the table ;)
>>> > >
>>> > > This is also related to the current status of build
>>> (Maven/Gradle).
>>> > >
>>> > > FYI, I gonna start the Jira triage tomorrow and I
>>> launched couple of
>>> > > build on my
>>> > > machine (both Maven and Gradle) to get an update on
>the
>>> current
>>> > status.
>>> > >
>>> > > Please, let me know if you have an opinion about
>Gradle
>>> vs Maven
>>> > for the
>>> > > release.
>>> > >
>>> > >
>>> > > Produced artifacts are still too different to use gradle
>>> IMHO. Jira were
>>> > > created but not yet fixed last time i tried gradle so
>clearly
>>> maven IMHO.
>>> > >
>>> > >
>>> > > Thanks !
>>> > > Regards
>>> > > JB
>>> > >
>>> > > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>>> > > > Hi guys,
>>> > > >
>>> > > > Apache Beam 2.4.0 has been released on March 20th.
>>> > > >
>>> > > > According to our cycle of release (roughly 6
>weeks), we
>>> should think
>>> > > about 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-04 Thread Scott Wegner
Hi JB, any idea when you will begin the release? Boyuan has a couple Python
PRs [1] [2] that are ready to merge, but we'd like to wait until after the
release branch is cut in case there is some performance regression.

[1] https://github.com/apache/beam/pull/4741
[2] https://github.com/apache/beam/pull/4925

On Tue, May 1, 2018 at 9:25 AM Scott Wegner  wrote:

> Sounds good, thanks J.B. Feel free to ping if you need anything.
>
> On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré 
> wrote:
>
>> That's a good idea ! I think using Slack to ping/ask is a good way as
>> it's async.
>>
>> Regards
>> JB
>>
>> On 05/01/2018 06:51 AM, Reuven Lax wrote:
>> > I think it makes sense to have someone who hadn't done the Gradle
>> migration to
>> > run the release. However would it make sense for someone who did work
>> on the
>> > migration to partner with you JB? There may be issues that are simply
>> due to
>> > things that were not documented well. In that case the partner can
>> quickly help
>> > resolve, and can then be the one who makes sure that the documentation
>> is updated.
>> >
>> > Reuven
>> >
>> > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré > > > wrote:
>> >
>> > Hi Scott,
>> >
>> > Thanks for the update. The Gradle build crashed on my machine (not
>> related to
>> > Gradle). I launched a new one.
>> >
>> > I'm volunteer to cut the release: I think I know Gradle decently,
>> and even if I
>> > didn't work on the gradle "migration" during the last two weeks, I
>> think it's
>> > actually better: I have an "external" view on the latest changes.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>> > On 05/01/2018 02:05 AM, Scott Wegner wrote:
>> > > Welcome back JB!
>> > >
>> > > I just sent a separate update about Gradle [1]-- the build
>> migration is
>> > complete
>> > > and the release documentation has been updated.
>> > >
>> > > I recommend we produce the 2.5.0 release using Gradle. Having a
>> successful
>> > > release should be the final validation before declaring the
>> Gradle migration
>> > > complete. So the sooner we can have a Gradle release, the sooner
>> we can
>> > get back
>> > > to a single build system :)
>> > >
>> > > If it would be helpful, I suggest that somebody who's been
>> working on the
>> > Gradle
>> > > migration to manage the 2.5.0 release. That way if we encounter
>> any issues
>> > from
>> > > the build system, they should have sufficient expertise to fix it.
>> > >
>> > >
>> > [1]
>> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>>
>> > >
>> > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > 
>> > > >>
>> wrote:
>> > >
>> > >
>> > >
>> > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré" <
>> j...@nanthrax.net
>> > 
>> > > >> a écrit :
>> > >
>> > > Hi guys,
>> > >
>> > > now that I'm back from vacations, I bring back 2.5.0
>> release on
>> > the table ;)
>> > >
>> > > This is also related to the current status of build
>> (Maven/Gradle).
>> > >
>> > > FYI, I gonna start the Jira triage tomorrow and I
>> launched couple of
>> > > build on my
>> > > machine (both Maven and Gradle) to get an update on the
>> current
>> > status.
>> > >
>> > > Please, let me know if you have an opinion about Gradle
>> vs Maven
>> > for the
>> > > release.
>> > >
>> > >
>> > > Produced artifacts are still too different to use gradle
>> IMHO. Jira were
>> > > created but not yet fixed last time i tried gradle so clearly
>> maven IMHO.
>> > >
>> > >
>> > > Thanks !
>> > > Regards
>> > > JB
>> > >
>> > > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>> > > > Hi guys,
>> > > >
>> > > > Apache Beam 2.4.0 has been released on March 20th.
>> > > >
>> > > > According to our cycle of release (roughly 6 weeks), we
>> should think
>> > > about 2.5.0.
>> > > >
>> > > > I'm volunteer to tackle this release.
>> > > >
>> > > > I'm proposing the following items:
>> > > >
>> > > > 1. We start the Jira triage now, up to Tuesday
>> > > > 2. I would like to cut the release on Tuesday night
>> (Europe time)
>> > > > 2bis. I think it's wiser to still use Maven for this
>> release. Do you
>> > >   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-05-01 Thread Scott Wegner
Sounds good, thanks J.B. Feel free to ping if you need anything.

On Mon, Apr 30, 2018 at 10:12 PM Jean-Baptiste Onofré 
wrote:

> That's a good idea ! I think using Slack to ping/ask is a good way as it's
> async.
>
> Regards
> JB
>
> On 05/01/2018 06:51 AM, Reuven Lax wrote:
> > I think it makes sense to have someone who hadn't done the Gradle
> migration to
> > run the release. However would it make sense for someone who did work on
> the
> > migration to partner with you JB? There may be issues that are simply
> due to
> > things that were not documented well. In that case the partner can
> quickly help
> > resolve, and can then be the one who makes sure that the documentation
> is updated.
> >
> > Reuven
> >
> > On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Scott,
> >
> > Thanks for the update. The Gradle build crashed on my machine (not
> related to
> > Gradle). I launched a new one.
> >
> > I'm volunteer to cut the release: I think I know Gradle decently,
> and even if I
> > didn't work on the gradle "migration" during the last two weeks, I
> think it's
> > actually better: I have an "external" view on the latest changes.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On 05/01/2018 02:05 AM, Scott Wegner wrote:
> > > Welcome back JB!
> > >
> > > I just sent a separate update about Gradle [1]-- the build
> migration is
> > complete
> > > and the release documentation has been updated.
> > >
> > > I recommend we produce the 2.5.0 release using Gradle. Having a
> successful
> > > release should be the final validation before declaring the Gradle
> migration
> > > complete. So the sooner we can have a Gradle release, the sooner
> we can
> > get back
> > > to a single build system :)
> > >
> > > If it would be helpful, I suggest that somebody who's been working
> on the
> > Gradle
> > > migration to manage the 2.5.0 release. That way if we encounter
> any issues
> > from
> > > the build system, they should have sufficient expertise to fix it.
> > >
> > >
> > [1]
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>
> > >
> > > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > 
> > > >>
> wrote:
> > >
> > >
> > >
> > > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  > 
> > > >> a écrit :
> > >
> > > Hi guys,
> > >
> > > now that I'm back from vacations, I bring back 2.5.0
> release on
> > the table ;)
> > >
> > > This is also related to the current status of build
> (Maven/Gradle).
> > >
> > > FYI, I gonna start the Jira triage tomorrow and I launched
> couple of
> > > build on my
> > > machine (both Maven and Gradle) to get an update on the
> current
> > status.
> > >
> > > Please, let me know if you have an opinion about Gradle vs
> Maven
> > for the
> > > release.
> > >
> > >
> > > Produced artifacts are still too different to use gradle IMHO.
> Jira were
> > > created but not yet fixed last time i tried gradle so clearly
> maven IMHO.
> > >
> > >
> > > Thanks !
> > > Regards
> > > JB
> > >
> > > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > > > Hi guys,
> > > >
> > > > Apache Beam 2.4.0 has been released on March 20th.
> > > >
> > > > According to our cycle of release (roughly 6 weeks), we
> should think
> > > about 2.5.0.
> > > >
> > > > I'm volunteer to tackle this release.
> > > >
> > > > I'm proposing the following items:
> > > >
> > > > 1. We start the Jira triage now, up to Tuesday
> > > > 2. I would like to cut the release on Tuesday night
> (Europe time)
> > > > 2bis. I think it's wiser to still use Maven for this
> release. Do you
> > > think we
> > > > will be ready to try a release with Gradle ?
> > > >
> > > > After this release, I would like a discussion about:
> > > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > > 2. Isolate release cycle per Beam part. I think it would
> be
> > > interesting to have
> > > > different release cycle: SDKs, DSLs, Runners, IOs.
> That's another
> > > discussion, I
> > > > will start a thread about 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Jean-Baptiste Onofré
That's a good idea ! I think using Slack to ping/ask is a good way as it's 
async.

Regards
JB

On 05/01/2018 06:51 AM, Reuven Lax wrote:
> I think it makes sense to have someone who hadn't done the Gradle migration to
> run the release. However would it make sense for someone who did work on the
> migration to partner with you JB? There may be issues that are simply due to
> things that were not documented well. In that case the partner can quickly 
> help
> resolve, and can then be the one who makes sure that the documentation is 
> updated.
> 
> Reuven
> 
> On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Scott,
> 
> Thanks for the update. The Gradle build crashed on my machine (not 
> related to
> Gradle). I launched a new one.
> 
> I'm volunteer to cut the release: I think I know Gradle decently, and 
> even if I
> didn't work on the gradle "migration" during the last two weeks, I think 
> it's
> actually better: I have an "external" view on the latest changes.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> On 05/01/2018 02:05 AM, Scott Wegner wrote:
> > Welcome back JB!
> >
> > I just sent a separate update about Gradle [1]-- the build migration is
> complete
> > and the release documentation has been updated.
> >
> > I recommend we produce the 2.5.0 release using Gradle. Having a 
> successful
> > release should be the final validation before declaring the Gradle 
> migration
> > complete. So the sooner we can have a Gradle release, the sooner we can
> get back
> > to a single build system :)
> >
> > If it would be helpful, I suggest that somebody who's been working on 
> the
> Gradle
> > migration to manage the 2.5.0 release. That way if we encounter any 
> issues
> from
> > the build system, they should have sufficient expertise to fix it.
> >
> >
> [1] 
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>  
> >
> > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau 
>  
> > >> wrote:
> >
> >
> >
> >     Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  
> >     >> a écrit :
> >
> >         Hi guys,
> >
> >         now that I'm back from vacations, I bring back 2.5.0 release on
> the table ;)
> >
> >         This is also related to the current status of build 
> (Maven/Gradle).
> >
> >         FYI, I gonna start the Jira triage tomorrow and I launched 
> couple of
> >         build on my
> >         machine (both Maven and Gradle) to get an update on the current
> status.
> >
> >         Please, let me know if you have an opinion about Gradle vs Maven
> for the
> >         release.
> >
> >
> >     Produced artifacts are still too different to use gradle IMHO. Jira 
> were
> >     created but not yet fixed last time i tried gradle so clearly maven 
> IMHO.
> >
> >
> >         Thanks !
> >         Regards
> >         JB
> >
> >         On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> >         > Hi guys,
> >         >
> >         > Apache Beam 2.4.0 has been released on March 20th.
> >         >
> >         > According to our cycle of release (roughly 6 weeks), we 
> should think
> >         about 2.5.0.
> >         >
> >         > I'm volunteer to tackle this release.
> >         >
> >         > I'm proposing the following items:
> >         >
> >         > 1. We start the Jira triage now, up to Tuesday
> >         > 2. I would like to cut the release on Tuesday night (Europe 
> time)
> >         > 2bis. I think it's wiser to still use Maven for this release. 
> Do you
> >         think we
> >         > will be ready to try a release with Gradle ?
> >         >
> >         > After this release, I would like a discussion about:
> >         > 1. Gradle release (if we release 2.5.0 with Maven)
> >         > 2. Isolate release cycle per Beam part. I think it would be
> >         interesting to have
> >         > different release cycle: SDKs, DSLs, Runners, IOs. That's 
> another
> >         discussion, I
> >         > will start a thread about that.
> >         >
> >         > Thoughts ?
> >         >
> >         > Regards
> >         > JB
> >         >
> >
> >         --
> >         Jean-Baptiste Onofré
> >         jbono...@apache.org 
> >
> >         

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Reuven Lax
I think it makes sense to have someone who hadn't done the Gradle migration
to run the release. However would it make sense for someone who did work on
the migration to partner with you JB? There may be issues that are simply
due to things that were not documented well. In that case the partner can
quickly help resolve, and can then be the one who makes sure that the
documentation is updated.

Reuven

On Mon, Apr 30, 2018 at 9:36 PM Jean-Baptiste Onofré 
wrote:

> Hi Scott,
>
> Thanks for the update. The Gradle build crashed on my machine (not related
> to
> Gradle). I launched a new one.
>
> I'm volunteer to cut the release: I think I know Gradle decently, and even
> if I
> didn't work on the gradle "migration" during the last two weeks, I think
> it's
> actually better: I have an "external" view on the latest changes.
>
> Thoughts ?
>
> Regards
> JB
>
> On 05/01/2018 02:05 AM, Scott Wegner wrote:
> > Welcome back JB!
> >
> > I just sent a separate update about Gradle [1]-- the build migration is
> complete
> > and the release documentation has been updated.
> >
> > I recommend we produce the 2.5.0 release using Gradle. Having a
> successful
> > release should be the final validation before declaring the Gradle
> migration
> > complete. So the sooner we can have a Gradle release, the sooner we can
> get back
> > to a single build system :)
> >
> > If it would be helpful, I suggest that somebody who's been working on
> the Gradle
> > migration to manage the 2.5.0 release. That way if we encounter any
> issues from
> > the build system, they should have sufficient expertise to fix it.
> >
> > [1]
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>
> >
> > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >
> >
> > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  > > a écrit :
> >
> > Hi guys,
> >
> > now that I'm back from vacations, I bring back 2.5.0 release on
> the table ;)
> >
> > This is also related to the current status of build
> (Maven/Gradle).
> >
> > FYI, I gonna start the Jira triage tomorrow and I launched
> couple of
> > build on my
> > machine (both Maven and Gradle) to get an update on the current
> status.
> >
> > Please, let me know if you have an opinion about Gradle vs Maven
> for the
> > release.
> >
> >
> > Produced artifacts are still too different to use gradle IMHO. Jira
> were
> > created but not yet fixed last time i tried gradle so clearly maven
> IMHO.
> >
> >
> > Thanks !
> > Regards
> > JB
> >
> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release (roughly 6 weeks), we should
> think
> > about 2.5.0.
> > >
> > > I'm volunteer to tackle this release.
> > >
> > > I'm proposing the following items:
> > >
> > > 1. We start the Jira triage now, up to Tuesday
> > > 2. I would like to cut the release on Tuesday night (Europe
> time)
> > > 2bis. I think it's wiser to still use Maven for this release.
> Do you
> > think we
> > > will be ready to try a release with Gradle ?
> > >
> > > After this release, I would like a discussion about:
> > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > 2. Isolate release cycle per Beam part. I think it would be
> > interesting to have
> > > different release cycle: SDKs, DSLs, Runners, IOs. That's
> another
> > discussion, I
> > > will start a thread about that.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> > --
> >
> >
> > Got feedback? http://go/swegner-feedback
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Thomas Weise
>
>
> I'm volunteer to cut the release: I think I know Gradle decently, and even
> if I
> didn't work on the gradle "migration" during the last two weeks, I think
> it's
> actually better: I have an "external" view on the latest changes.
>
>
+1

Since we expect the community overall to be able to work with the new
Gradle build such "external" release manager would be another good
validation.

Thanks,
Thomas



> Thoughts ?
>
> Regards
> JB
>
> On 05/01/2018 02:05 AM, Scott Wegner wrote:
> > Welcome back JB!
> >
> > I just sent a separate update about Gradle [1]-- the build migration is
> complete
> > and the release documentation has been updated.
> >
> > I recommend we produce the 2.5.0 release using Gradle. Having a
> successful
> > release should be the final validation before declaring the Gradle
> migration
> > complete. So the sooner we can have a Gradle release, the sooner we can
> get back
> > to a single build system :)
> >
> > If it would be helpful, I suggest that somebody who's been working on
> the Gradle
> > migration to manage the 2.5.0 release. That way if we encounter any
> issues from
> > the build system, they should have sufficient expertise to fix it.
> >
> > [1] https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4
> 131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
> >
> > On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >
> >
> > Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  > > a écrit :
> >
> > Hi guys,
> >
> > now that I'm back from vacations, I bring back 2.5.0 release on
> the table ;)
> >
> > This is also related to the current status of build
> (Maven/Gradle).
> >
> > FYI, I gonna start the Jira triage tomorrow and I launched
> couple of
> > build on my
> > machine (both Maven and Gradle) to get an update on the current
> status.
> >
> > Please, let me know if you have an opinion about Gradle vs Maven
> for the
> > release.
> >
> >
> > Produced artifacts are still too different to use gradle IMHO. Jira
> were
> > created but not yet fixed last time i tried gradle so clearly maven
> IMHO.
> >
> >
> > Thanks !
> > Regards
> > JB
> >
> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release (roughly 6 weeks), we should
> think
> > about 2.5.0.
> > >
> > > I'm volunteer to tackle this release.
> > >
> > > I'm proposing the following items:
> > >
> > > 1. We start the Jira triage now, up to Tuesday
> > > 2. I would like to cut the release on Tuesday night (Europe
> time)
> > > 2bis. I think it's wiser to still use Maven for this release.
> Do you
> > think we
> > > will be ready to try a release with Gradle ?
> > >
> > > After this release, I would like a discussion about:
> > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > 2. Isolate release cycle per Beam part. I think it would be
> > interesting to have
> > > different release cycle: SDKs, DSLs, Runners, IOs. That's
> another
> > discussion, I
> > > will start a thread about that.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
> > --
> >
> >
> > Got feedback? http://go/swegner-feedback
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Jean-Baptiste Onofré
Hi Scott,

Thanks for the update. The Gradle build crashed on my machine (not related to
Gradle). I launched a new one.

I'm volunteer to cut the release: I think I know Gradle decently, and even if I
didn't work on the gradle "migration" during the last two weeks, I think it's
actually better: I have an "external" view on the latest changes.

Thoughts ?

Regards
JB

On 05/01/2018 02:05 AM, Scott Wegner wrote:
> Welcome back JB!
> 
> I just sent a separate update about Gradle [1]-- the build migration is 
> complete
> and the release documentation has been updated.
> 
> I recommend we produce the 2.5.0 release using Gradle. Having a successful
> release should be the final validation before declaring the Gradle migration
> complete. So the sooner we can have a Gradle release, the sooner we can get 
> back
> to a single build system :)
> 
> If it would be helpful, I suggest that somebody who's been working on the 
> Gradle
> migration to manage the 2.5.0 release. That way if we encounter any issues 
> from
> the build system, they should have sufficient expertise to fix it.
> 
> [1] 
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>  
> 
> On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau  > wrote:
> 
> 
> 
> Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  > a écrit :
> 
> Hi guys,
> 
> now that I'm back from vacations, I bring back 2.5.0 release on the 
> table ;)
> 
> This is also related to the current status of build (Maven/Gradle).
> 
> FYI, I gonna start the Jira triage tomorrow and I launched couple of
> build on my
> machine (both Maven and Gradle) to get an update on the current 
> status.
> 
> Please, let me know if you have an opinion about Gradle vs Maven for 
> the
> release.
> 
> 
> Produced artifacts are still too different to use gradle IMHO. Jira were
> created but not yet fixed last time i tried gradle so clearly maven IMHO.
> 
> 
> Thanks !
> Regards
> JB
> 
> On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be
> interesting to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 
> 
> -- 
> 
> 
> Got feedback? http://go/swegner-feedback

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Lukasz Cwik
I also agree that the release should be done using Gradle otherwise we
won't have the opportunity to migrate off of Maven for several more weeks
till 2.6.0 is released. Several people have pointed out that supporting
multiple build systems is a hassle which is what inspired putting more
effort into the migration effort.

On Mon, Apr 30, 2018 at 5:05 PM Scott Wegner  wrote:

> Welcome back JB!
>
> I just sent a separate update about Gradle [1]-- the build migration is
> complete and the release documentation has been updated.
>
> I recommend we produce the 2.5.0 release using Gradle. Having a successful
> release should be the final validation before declaring the Gradle
> migration complete. So the sooner we can have a Gradle release, the sooner
> we can get back to a single build system :)
>
> If it would be helpful, I suggest that somebody who's been working on the
> Gradle migration to manage the 2.5.0 release. That way if we encounter any
> issues from the build system, they should have sufficient expertise to fix
> it.
>
> [1]
> https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E
>
>
> On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau 
> wrote:
>
>>
>>
>> Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  a écrit :
>>
>> Hi guys,
>>
>> now that I'm back from vacations, I bring back 2.5.0 release on the table
>> ;)
>>
>> This is also related to the current status of build (Maven/Gradle).
>>
>> FYI, I gonna start the Jira triage tomorrow and I launched couple of
>> build on my
>> machine (both Maven and Gradle) to get an update on the current status.
>>
>> Please, let me know if you have an opinion about Gradle vs Maven for the
>> release.
>>
>>
>> Produced artifacts are still too different to use gradle IMHO. Jira were
>> created but not yet fixed last time i tried gradle so clearly maven IMHO.
>>
>>
>> Thanks !
>> Regards
>> JB
>>
>> On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should think
>> about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe time)
>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>> think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be interesting
>> to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>> --
>
>
> Got feedback? http://go/swegner-feedback
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Scott Wegner
Welcome back JB!

I just sent a separate update about Gradle [1]-- the build migration is
complete and the release documentation has been updated.

I recommend we produce the 2.5.0 release using Gradle. Having a successful
release should be the final validation before declaring the Gradle
migration complete. So the sooner we can have a Gradle release, the sooner
we can get back to a single build system :)

If it would be helpful, I suggest that somebody who's been working on the
Gradle migration to manage the 2.5.0 release. That way if we encounter any
issues from the build system, they should have sufficient expertise to fix
it.

[1]
https://lists.apache.org/thread.html/e543b3850bfc4950d57bc18624e1d4131324c6cf691fd10034947cad@%3Cdev.beam.apache.org%3E


On Mon, Apr 30, 2018 at 11:38 AM Romain Manni-Bucau 
wrote:

>
>
> Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  a écrit :
>
> Hi guys,
>
> now that I'm back from vacations, I bring back 2.5.0 release on the table
> ;)
>
> This is also related to the current status of build (Maven/Gradle).
>
> FYI, I gonna start the Jira triage tomorrow and I launched couple of build
> on my
> machine (both Maven and Gradle) to get an update on the current status.
>
> Please, let me know if you have an opinion about Gradle vs Maven for the
> release.
>
>
> Produced artifacts are still too different to use gradle IMHO. Jira were
> created but not yet fixed last time i tried gradle so clearly maven IMHO.
>
>
> Thanks !
> Regards
> JB
>
> On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> --


Got feedback? http://go/swegner-feedback


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Romain Manni-Bucau
Le 30 avr. 2018 19:39, "Jean-Baptiste Onofré"  a écrit :

Hi guys,

now that I'm back from vacations, I bring back 2.5.0 release on the table ;)

This is also related to the current status of build (Maven/Gradle).

FYI, I gonna start the Jira triage tomorrow and I launched couple of build
on my
machine (both Maven and Gradle) to get an update on the current status.

Please, let me know if you have an opinion about Gradle vs Maven for the
release.


Produced artifacts are still too different to use gradle IMHO. Jira were
created but not yet fixed last time i tried gradle so clearly maven IMHO.


Thanks !
Regards
JB

On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> Hi guys,
>
> Apache Beam 2.4.0 has been released on March 20th.
>
> According to our cycle of release (roughly 6 weeks), we should think
about 2.5.0.
>
> I'm volunteer to tackle this release.
>
> I'm proposing the following items:
>
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you
think we
> will be ready to try a release with Gradle ?
>
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be interesting
to have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another
discussion, I
> will start a thread about that.
>
> Thoughts ?
>
> Regards
> JB
>

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-30 Thread Jean-Baptiste Onofré
Hi guys,

now that I'm back from vacations, I bring back 2.5.0 release on the table ;)

This is also related to the current status of build (Maven/Gradle).

FYI, I gonna start the Jira triage tomorrow and I launched couple of build on my
machine (both Maven and Gradle) to get an update on the current status.

Please, let me know if you have an opinion about Gradle vs Maven for the 
release.

Thanks !
Regards
JB

On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> Apache Beam 2.4.0 has been released on March 20th.
> 
> According to our cycle of release (roughly 6 weeks), we should think about 
> 2.5.0.
> 
> I'm volunteer to tackle this release.
> 
> I'm proposing the following items:
> 
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you think we
> will be ready to try a release with Gradle ?
> 
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be interesting to 
> have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, 
> I
> will start a thread about that.
> 
> Thoughts ?
> 
> Regards
> JB
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-18 Thread Ismaël Mejía
Most criticla pending issues to test before a gradle based release is
that those generated poms are equal to the maven ones. Which means
that they don't add by mistake compile dependencies where they were
not.

It is also critical to validate that all the meta-info is generated as
it was done with Maven.

For ref:.
https://issues.apache.org/jira/browse/BEAM-4057
https://issues.apache.org/jira/browse/BEAM-4060




On Wed, Apr 18, 2018 at 7:09 PM, Alan Myrvold  wrote:
> We have been generating a maven project using the archetype from gradle
> built snapshot releases and running the quickstarts using maven.
>
> Are there other interesting tests to try that the quickstarts miss?
>
> On Thu, Apr 12, 2018 at 9:21 AM Kenneth Knowles  wrote:
>>
>> Just because I have probably missed it in the flood of work/emails (yay!)
>> have we been dry-running the user experience of a Maven-built project
>> depending on Beam? If declaring a dependency on Beam doesn't work in some
>> basic way, it seems like we would want to know that right away. Our release
>> verification will definitely catch this, but perhaps we want to check it
>> earlier.
>>
>> Kenn
>>
>> On Thu, Apr 12, 2018 at 9:11 AM Scott Wegner  wrote:
>>>
>>> Romain, could you please open a JIRA describing the requirements for the
>>> generated pom's? The gradle-generated pom's don't match the maven version
>>> byte-for-byte, but I don't think that's a requirement.
>>>
>>> I and others are still hacking on the Gradle build, so it's possible we
>>> could get the pom's ready within 2 weeks. It would be good to understand the
>>> specific requirements for the generated pom's such that we don't break
>>> consumers.
>>>
>>> On Thu, Apr 12, 2018 at 3:14 AM Etienne Chauchot 
>>> wrote:

 +1 to what Ahmet said,  I also think that it is important to take our
 time given that we're in the gradle migration process.
 +1 to what JB said also: try gradle and fall back to maven in case of
 troubles.

 Etienne

 Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :

 +1 to delaying 2 weeks.

 I think it will be prudent to wait in this case. There is too much in
 flux with Gradle migration currently and based on Scott's latest update I
 think we will be in a more stable state in 2 weeks. Last Beam release date
 was 3/20 and our plan was to make a release every 6 weeks. Even if we start
 cutting a release in 2 weeks (~4/26), we will have more than a week to
 finish that release. Even if that is not enough time to finish a release it
 will put is in the proximity of the 5/5 target date. I prefer that option,
 to another potential release with Maven.

 On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau
  wrote:

 Any hope the release is on central before the 30th?


 I do not think this was the plan to begin with. The time between the
 previous release and 4/30 is less than 6 weeks.



 Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :

 +1 to keeping up the regular release cycle, but I don't think it makes
 sense to cut until we're ready to actively work on the release. A cut date
 two weeks from now seems fine (unless someone else is volunteering to do it
 this time around).

 That being said, a dry run using gradle now may make a lot of sense,
 giving us a couple of weeks to iron out the kinks, if any.

 On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath
  wrote:

 Hi JB,

 Please note that I opened a blocker [1] (working on it) and looks like
 we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
 weeks (or till JIRAs are resolved or moved off the list).

 Thanks,
 Cham

 [1] https://issues.apache.org/jira/browse/BEAM-3991
 [2]
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC

 On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
 wrote:

 Hi guys,

 Due to the last work, I think it makes sense to try a release using
 Gradle. If it doesn't work smoothly, we will rollback to Maven, and
 maybe in that case, we should ask ourselves if Gradle is really a good
 alternative for now.

 I'm in vacation tomorrow morning for 2 weeks. I can cut the release
 tomorrow end of the morning (my time). But in the case we need some
 additional PR merges or we have some work in progress, I'm proposing to
 postpone 2.5.0 release for the end of this month (in two weeks). If
 someone is volunteer to tackle this release, please, let us know.

 Regards
 JB

 On 06/04/2018 10:48, 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-18 Thread Alan Myrvold
We have been generating a maven project using the archetype from gradle
built snapshot releases and running the quickstarts using maven.

Are there other interesting tests to try that the quickstarts miss?

On Thu, Apr 12, 2018 at 9:21 AM Kenneth Knowles  wrote:

> Just because I have probably missed it in the flood of work/emails (yay!)
> have we been dry-running the user experience of a Maven-built project
> depending on Beam? If declaring a dependency on Beam doesn't work in some
> basic way, it seems like we would want to know that right away. Our release
> verification will definitely catch this, but perhaps we want to check it
> earlier.
>
> Kenn
>
> On Thu, Apr 12, 2018 at 9:11 AM Scott Wegner  wrote:
>
>> Romain, could you please open a JIRA describing the requirements for the
>> generated pom's? The gradle-generated pom's don't match the maven version
>> byte-for-byte, but I don't think that's a requirement.
>>
>> I and others are still hacking on the Gradle build, so it's possible we
>> could get the pom's ready within 2 weeks. It would be good to understand
>> the specific requirements for the generated pom's such that we don't break
>> consumers.
>>
>> On Thu, Apr 12, 2018 at 3:14 AM Etienne Chauchot 
>> wrote:
>>
>>> +1 to what Ahmet said,  I also think that it is important to take our
>>> time given that we're in the gradle migration process.
>>> +1 to what JB said also: try gradle and fall back to maven in case of
>>> troubles.
>>>
>>> Etienne
>>>
>>> Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :
>>>
>>> +1 to delaying 2 weeks.
>>>
>>> I think it will be prudent to wait in this case. There is too much in
>>> flux with Gradle migration currently and based on Scott's latest update I
>>> think we will be in a more stable state in 2 weeks. Last Beam release date
>>> was 3/20 and our plan was to make a release every 6 weeks. Even if we start
>>> cutting a release in 2 weeks (~4/26), we will have more than a week to
>>> finish that release. Even if that is not enough time to finish a release it
>>> will put is in the proximity of the 5/5 target date. I prefer that option,
>>> to another potential release with Maven.
>>>
>>> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>> Any hope the release is on central before the 30th?
>>>
>>>
>>> I do not think this was the plan to begin with. The time between the
>>> previous release and 4/30 is less than 6 weeks.
>>>
>>>
>>>
>>> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>>>
>>> +1 to keeping up the regular release cycle, but I don't think it makes
>>> sense to cut until we're ready to actively work on the release. A cut date
>>> two weeks from now seems fine (unless someone else is volunteering to do it
>>> this time around).
>>>
>>> That being said, a dry run using gradle now may make a lot of sense,
>>> giving us a couple of weeks to iron out the kinks, if any.
>>>
>>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath <
>>> chamik...@google.com> wrote:
>>>
>>> Hi JB,
>>>
>>> Please note that I opened a blocker [1] (working on it) and looks like
>>> we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
>>> weeks (or till JIRAs are resolved or moved off the list).
>>>
>>> Thanks,
>>> Cham
>>>
>>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>>> [2]
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>>
>>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
>>> wrote:
>>>
>>> Hi guys,
>>>
>>> Due to the last work, I think it makes sense to try a release using
>>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>>> maybe in that case, we should ask ourselves if Gradle is really a good
>>> alternative for now.
>>>
>>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>>> tomorrow end of the morning (my time). But in the case we need some
>>> additional PR merges or we have some work in progress, I'm proposing to
>>> postpone 2.5.0 release for the end of this month (in two weeks). If
>>> someone is volunteer to tackle this release, please, let us know.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> > Hi guys,
>>> >
>>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >
>>> > According to our cycle of release (roughly 6 weeks), we should think
>>> about 2.5.0.
>>> >
>>> > I'm volunteer to tackle this release.
>>> >
>>> > I'm proposing the following items:
>>> >
>>> > 1. We start the Jira triage now, up to Tuesday
>>> > 2. I would like to cut the release on Tuesday night (Europe time)
>>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>>> think we
>>> > will be ready to try a release with Gradle ?
>>> >
>>> > After this release, I would 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-12 Thread Kenneth Knowles
Just because I have probably missed it in the flood of work/emails (yay!)
have we been dry-running the user experience of a Maven-built project
depending on Beam? If declaring a dependency on Beam doesn't work in some
basic way, it seems like we would want to know that right away. Our release
verification will definitely catch this, but perhaps we want to check it
earlier.

Kenn

On Thu, Apr 12, 2018 at 9:11 AM Scott Wegner  wrote:

> Romain, could you please open a JIRA describing the requirements for the
> generated pom's? The gradle-generated pom's don't match the maven version
> byte-for-byte, but I don't think that's a requirement.
>
> I and others are still hacking on the Gradle build, so it's possible we
> could get the pom's ready within 2 weeks. It would be good to understand
> the specific requirements for the generated pom's such that we don't break
> consumers.
>
> On Thu, Apr 12, 2018 at 3:14 AM Etienne Chauchot 
> wrote:
>
>> +1 to what Ahmet said,  I also think that it is important to take our
>> time given that we're in the gradle migration process.
>> +1 to what JB said also: try gradle and fall back to maven in case of
>> troubles.
>>
>> Etienne
>>
>> Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :
>>
>> +1 to delaying 2 weeks.
>>
>> I think it will be prudent to wait in this case. There is too much in
>> flux with Gradle migration currently and based on Scott's latest update I
>> think we will be in a more stable state in 2 weeks. Last Beam release date
>> was 3/20 and our plan was to make a release every 6 weeks. Even if we start
>> cutting a release in 2 weeks (~4/26), we will have more than a week to
>> finish that release. Even if that is not enough time to finish a release it
>> will put is in the proximity of the 5/5 target date. I prefer that option,
>> to another potential release with Maven.
>>
>> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>> Any hope the release is on central before the 30th?
>>
>>
>> I do not think this was the plan to begin with. The time between the
>> previous release and 4/30 is less than 6 weeks.
>>
>>
>>
>> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>>
>> +1 to keeping up the regular release cycle, but I don't think it makes
>> sense to cut until we're ready to actively work on the release. A cut date
>> two weeks from now seems fine (unless someone else is volunteering to do it
>> this time around).
>>
>> That being said, a dry run using gradle now may make a lot of sense,
>> giving us a couple of weeks to iron out the kinks, if any.
>>
>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
>> wrote:
>>
>> Hi JB,
>>
>> Please note that I opened a blocker [1] (working on it) and looks like we
>> have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
>> (or till JIRAs are resolved or moved off the list).
>>
>> Thanks,
>> Cham
>>
>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>> [2]
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>
>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
>> wrote:
>>
>> Hi guys,
>>
>> Due to the last work, I think it makes sense to try a release using
>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>> maybe in that case, we should ask ourselves if Gradle is really a good
>> alternative for now.
>>
>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>> tomorrow end of the morning (my time). But in the case we need some
>> additional PR merges or we have some work in progress, I'm proposing to
>> postpone 2.5.0 release for the end of this month (in two weeks). If
>> someone is volunteer to tackle this release, please, let us know.
>>
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should think
>> about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe time)
>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>> think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be interesting
>> to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>>
>>
>>
>>
>>
>> --
>
>
> Got feedback? 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-12 Thread Romain Manni-Bucau
created https://issues.apache.org/jira/browse/BEAM-4057

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


2018-04-12 18:11 GMT+02:00 Scott Wegner :
> Romain, could you please open a JIRA describing the requirements for the
> generated pom's? The gradle-generated pom's don't match the maven version
> byte-for-byte, but I don't think that's a requirement.
>
> I and others are still hacking on the Gradle build, so it's possible we
> could get the pom's ready within 2 weeks. It would be good to understand the
> specific requirements for the generated pom's such that we don't break
> consumers.
>
> On Thu, Apr 12, 2018 at 3:14 AM Etienne Chauchot 
> wrote:
>>
>> +1 to what Ahmet said,  I also think that it is important to take our time
>> given that we're in the gradle migration process.
>> +1 to what JB said also: try gradle and fall back to maven in case of
>> troubles.
>>
>> Etienne
>>
>> Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :
>>
>> +1 to delaying 2 weeks.
>>
>> I think it will be prudent to wait in this case. There is too much in flux
>> with Gradle migration currently and based on Scott's latest update I think
>> we will be in a more stable state in 2 weeks. Last Beam release date was
>> 3/20 and our plan was to make a release every 6 weeks. Even if we start
>> cutting a release in 2 weeks (~4/26), we will have more than a week to
>> finish that release. Even if that is not enough time to finish a release it
>> will put is in the proximity of the 5/5 target date. I prefer that option,
>> to another potential release with Maven.
>>
>> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau
>>  wrote:
>>
>> Any hope the release is on central before the 30th?
>>
>>
>> I do not think this was the plan to begin with. The time between the
>> previous release and 4/30 is less than 6 weeks.
>>
>>
>>
>> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>>
>> +1 to keeping up the regular release cycle, but I don't think it makes
>> sense to cut until we're ready to actively work on the release. A cut date
>> two weeks from now seems fine (unless someone else is volunteering to do it
>> this time around).
>>
>> That being said, a dry run using gradle now may make a lot of sense,
>> giving us a couple of weeks to iron out the kinks, if any.
>>
>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
>> wrote:
>>
>> Hi JB,
>>
>> Please note that I opened a blocker [1] (working on it) and looks like we
>> have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
>> (or till JIRAs are resolved or moved off the list).
>>
>> Thanks,
>> Cham
>>
>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>> [2]
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>
>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
>> wrote:
>>
>> Hi guys,
>>
>> Due to the last work, I think it makes sense to try a release using
>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>> maybe in that case, we should ask ourselves if Gradle is really a good
>> alternative for now.
>>
>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>> tomorrow end of the morning (my time). But in the case we need some
>> additional PR merges or we have some work in progress, I'm proposing to
>> postpone 2.5.0 release for the end of this month (in two weeks). If
>> someone is volunteer to tackle this release, please, let us know.
>>
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should think
>> > about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe time)
>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>> > think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be interesting
>> > to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> > discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>>
>>
>>
>>
>>
> --
>
>
> Got feedback? http://go/swegner-feedback


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-12 Thread Scott Wegner
Romain, could you please open a JIRA describing the requirements for the
generated pom's? The gradle-generated pom's don't match the maven version
byte-for-byte, but I don't think that's a requirement.

I and others are still hacking on the Gradle build, so it's possible we
could get the pom's ready within 2 weeks. It would be good to understand
the specific requirements for the generated pom's such that we don't break
consumers.

On Thu, Apr 12, 2018 at 3:14 AM Etienne Chauchot 
wrote:

> +1 to what Ahmet said,  I also think that it is important to take our time
> given that we're in the gradle migration process.
> +1 to what JB said also: try gradle and fall back to maven in case of
> troubles.
>
> Etienne
>
> Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :
>
> +1 to delaying 2 weeks.
>
> I think it will be prudent to wait in this case. There is too much in flux
> with Gradle migration currently and based on Scott's latest update I think
> we will be in a more stable state in 2 weeks. Last Beam release date was
> 3/20 and our plan was to make a release every 6 weeks. Even if we start
> cutting a release in 2 weeks (~4/26), we will have more than a week to
> finish that release. Even if that is not enough time to finish a release it
> will put is in the proximity of the 5/5 target date. I prefer that option,
> to another potential release with Maven.
>
> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau  > wrote:
>
> Any hope the release is on central before the 30th?
>
>
> I do not think this was the plan to begin with. The time between the
> previous release and 4/30 is less than 6 weeks.
>
>
>
> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>
> +1 to keeping up the regular release cycle, but I don't think it makes
> sense to cut until we're ready to actively work on the release. A cut date
> two weeks from now seems fine (unless someone else is volunteering to do it
> this time around).
>
> That being said, a dry run using gradle now may make a lot of sense,
> giving us a couple of weeks to iron out the kinks, if any.
>
> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
> wrote:
>
> Hi JB,
>
> Please note that I opened a blocker [1] (working on it) and looks like we
> have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
> (or till JIRAs are resolved or moved off the list).
>
> Thanks,
> Cham
>
> [1] https://issues.apache.org/jira/browse/BEAM-3991
> [2]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>
> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
> wrote:
>
> Hi guys,
>
> Due to the last work, I think it makes sense to try a release using
> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
> maybe in that case, we should ask ourselves if Gradle is really a good
> alternative for now.
>
> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
> tomorrow end of the morning (my time). But in the case we need some
> additional PR merges or we have some work in progress, I'm proposing to
> postpone 2.5.0 release for the end of this month (in two weeks). If
> someone is volunteer to tackle this release, please, let us know.
>
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
>
>
>
>
> --


Got feedback? http://go/swegner-feedback


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-12 Thread Etienne Chauchot
+1 to what Ahmet said,  I also think that it is important to take our time 
given that we're in the gradle migration
process.
+1 to what JB said also: try gradle and fall back to maven in case of troubles.
Etienne
Le mercredi 11 avril 2018 à 13:35 -0700, Ahmet Altay a écrit :
> +1 to delaying 2 weeks.
> 
> I think it will be prudent to wait in this case. There is too much in flux 
> with Gradle migration currently and based
> on Scott's latest update I think we will be in a more stable state in 2 
> weeks. Last Beam release date was 3/20 and our
> plan was to make a release every 6 weeks. Even if we start cutting a release 
> in 2 weeks (~4/26), we will have more
> than a week to finish that release. Even if that is not enough time to finish 
> a release it will put is in the
> proximity of the 5/5 target date. I prefer that option, to another potential 
> release with Maven.
> 
> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau  
> wrote:
> > Any hope the release is on central before the 30th?
> > 
> I do not think this was the plan to begin with. The time between the previous 
> release and 4/30 is less than 6 weeks.
>  
> > 
> > Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
> > > +1 to keeping up the regular release cycle, but I don't think it makes 
> > > sense to cut until we're ready to actively
> > > work on the release. A cut date two weeks from now seems fine (unless 
> > > someone else is volunteering to do it this
> > > time around). 
> > > 
> > > That being said, a dry run using gradle now may make a lot of sense, 
> > > giving us a couple of weeks to iron out the
> > > kinks, if any. 
> > > 
> > > On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
> > >  wrote:
> > > > Hi JB,
> > > > 
> > > > Please note that I opened a blocker [1] (working on it) and looks like 
> > > > we have several other JIRAs marked for
> > > > 2.5.0. So +1 for waiting for two weeks (or till JIRAs are resolved or 
> > > > moved off the list).
> > > > 
> > > > Thanks,
> > > > Cham
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/BEAM-3991
> > > > [2] 
> > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > > 20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
> > > > 
> > > > On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
> > > >  wrote:
> > > > > Hi guys,
> > > > > 
> > > > > Due to the last work, I think it makes sense to try a release using 
> > > > > Gradle. If it doesn't work smoothly, we will rollback to Maven, and 
> > > > > maybe in that case, we should ask ourselves if Gradle is really a 
> > > > > good 
> > > > > alternative for now.
> > > > > 
> > > > > I'm in vacation tomorrow morning for 2 weeks. I can cut the release 
> > > > > tomorrow end of the morning (my time). But in the case we need some 
> > > > > additional PR merges or we have some work in progress, I'm proposing 
> > > > > to 
> > > > > postpone 2.5.0 release for the end of this month (in two weeks). If 
> > > > > someone is volunteer to tackle this release, please, let us know.
> > > > > 
> > > > > Regards
> > > > > JB
> > > > > 
> > > > > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > Apache Beam 2.4.0 has been released on March 20th.
> > > > > > 
> > > > > > According to our cycle of release (roughly 6 weeks), we should 
> > > > > > think about 2.5.0.
> > > > > > 
> > > > > > I'm volunteer to tackle this release.
> > > > > > 
> > > > > > I'm proposing the following items:
> > > > > > 
> > > > > > 1. We start the Jira triage now, up to Tuesday
> > > > > > 2. I would like to cut the release on Tuesday night (Europe time)
> > > > > > 2bis. I think it's wiser to still use Maven for this release. Do 
> > > > > > you think we
> > > > > > will be ready to try a release with Gradle ?
> > > > > > 
> > > > > > After this release, I would like a discussion about:
> > > > > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > > > > 2. Isolate release cycle per Beam part. I think it would be 
> > > > > > interesting to have
> > > > > > different release cycle: SDKs, DSLs, Runners, IOs. That's another 
> > > > > > discussion, I
> > > > > > will start a thread about that.
> > > > > > 
> > > > > > Thoughts ?
> > > > > > 
> > > > > > Regards
> > > > > > JB
> > > > > > 
> > > > > 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Romain Manni-Bucau
Is it possible to delay it of 2 more weeks then? ~16th?

Without a lot of effort on pom generation, maven consumer will be broken
and I will ot be able to work on that (or something else ;)) the two first
weeks of may. Alternatively, a compromise can be to push existing poms
until we drop them. They will be more correct with almost no effort.


Le 11 avr. 2018 23:21, "Ismaël Mejía"  a écrit :

> +1 to delay 2 weeks as Ahmet proposes. We can cut the branch in two
> weeks in a more stable shape doing it right now is not a good idea.
> We can justify the delay on the impact of transitioning the build system.
>
>
> On Wed, Apr 11, 2018 at 10:35 PM, Ahmet Altay  wrote:
> > +1 to delaying 2 weeks.
> >
> > I think it will be prudent to wait in this case. There is too much in
> flux
> > with Gradle migration currently and based on Scott's latest update I
> think
> > we will be in a more stable state in 2 weeks. Last Beam release date was
> > 3/20 and our plan was to make a release every 6 weeks. Even if we start
> > cutting a release in 2 weeks (~4/26), we will have more than a week to
> > finish that release. Even if that is not enough time to finish a release
> it
> > will put is in the proximity of the 5/5 target date. I prefer that
> option,
> > to another potential release with Maven.
> >
> > On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >>
> >> Any hope the release is on central before the 30th?
> >
> >
> > I do not think this was the plan to begin with. The time between the
> > previous release and 4/30 is less than 6 weeks.
> >
> >>
> >>
> >> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit
> :
> >>>
> >>> +1 to keeping up the regular release cycle, but I don't think it makes
> >>> sense to cut until we're ready to actively work on the release. A cut
> date
> >>> two weeks from now seems fine (unless someone else is volunteering to
> do it
> >>> this time around).
> >>>
> >>> That being said, a dry run using gradle now may make a lot of sense,
> >>> giving us a couple of weeks to iron out the kinks, if any.
> >>>
> >>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath
> >>>  wrote:
> 
>  Hi JB,
> 
>  Please note that I opened a blocker [1] (working on it) and looks like
>  we have several other JIRAs marked for 2.5.0. So +1 for waiting for
> two
>  weeks (or till JIRAs are resolved or moved off the list).
> 
>  Thanks,
>  Cham
> 
>  [1] https://issues.apache.org/jira/browse/BEAM-3991
>  [2]
>  https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
> 
>  On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré <
> j...@nanthrax.net>
>  wrote:
> >
> > Hi guys,
> >
> > Due to the last work, I think it makes sense to try a release using
> > Gradle. If it doesn't work smoothly, we will rollback to Maven, and
> > maybe in that case, we should ask ourselves if Gradle is really a
> good
> > alternative for now.
> >
> > I'm in vacation tomorrow morning for 2 weeks. I can cut the release
> > tomorrow end of the morning (my time). But in the case we need some
> > additional PR merges or we have some work in progress, I'm proposing
> to
> > postpone 2.5.0 release for the end of this month (in two weeks). If
> > someone is volunteer to tackle this release, please, let us know.
> >
> > Regards
> > JB
> >
> > On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release (roughly 6 weeks), we should
> think
> > > about 2.5.0.
> > >
> > > I'm volunteer to tackle this release.
> > >
> > > I'm proposing the following items:
> > >
> > > 1. We start the Jira triage now, up to Tuesday
> > > 2. I would like to cut the release on Tuesday night (Europe time)
> > > 2bis. I think it's wiser to still use Maven for this release. Do
> you
> > > think we
> > > will be ready to try a release with Gradle ?
> > >
> > > After this release, I would like a discussion about:
> > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > 2. Isolate release cycle per Beam part. I think it would be
> > > interesting to have
> > > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> > > discussion, I
> > > will start a thread about that.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> >
> >
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Jean-Baptiste Onofré
+1 agree to wait two weeks.

So I will tackle the release when back from vacation.

Thanks guys ! I can take off serene ;)

Regards
JB

On 04/11/2018 11:20 PM, Ismaël Mejía wrote:
> +1 to delay 2 weeks as Ahmet proposes. We can cut the branch in two
> weeks in a more stable shape doing it right now is not a good idea.
> We can justify the delay on the impact of transitioning the build system.
> 
> 
> On Wed, Apr 11, 2018 at 10:35 PM, Ahmet Altay  wrote:
>> +1 to delaying 2 weeks.
>>
>> I think it will be prudent to wait in this case. There is too much in flux
>> with Gradle migration currently and based on Scott's latest update I think
>> we will be in a more stable state in 2 weeks. Last Beam release date was
>> 3/20 and our plan was to make a release every 6 weeks. Even if we start
>> cutting a release in 2 weeks (~4/26), we will have more than a week to
>> finish that release. Even if that is not enough time to finish a release it
>> will put is in the proximity of the 5/5 target date. I prefer that option,
>> to another potential release with Maven.
>>
>> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau 
>> wrote:
>>>
>>> Any hope the release is on central before the 30th?
>>
>>
>> I do not think this was the plan to begin with. The time between the
>> previous release and 4/30 is less than 6 weeks.
>>
>>>
>>>
>>> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :

 +1 to keeping up the regular release cycle, but I don't think it makes
 sense to cut until we're ready to actively work on the release. A cut date
 two weeks from now seems fine (unless someone else is volunteering to do it
 this time around).

 That being said, a dry run using gradle now may make a lot of sense,
 giving us a couple of weeks to iron out the kinks, if any.

 On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath
  wrote:
>
> Hi JB,
>
> Please note that I opened a blocker [1] (working on it) and looks like
> we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
> weeks (or till JIRAs are resolved or moved off the list).
>
> Thanks,
> Cham
>
> [1] https://issues.apache.org/jira/browse/BEAM-3991
> [2]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>
> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
> wrote:
>>
>> Hi guys,
>>
>> Due to the last work, I think it makes sense to try a release using
>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>> maybe in that case, we should ask ourselves if Gradle is really a good
>> alternative for now.
>>
>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>> tomorrow end of the morning (my time). But in the case we need some
>> additional PR merges or we have some work in progress, I'm proposing to
>> postpone 2.5.0 release for the end of this month (in two weeks). If
>> someone is volunteer to tackle this release, please, let us know.
>>
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> Hi guys,
>>>
>>> Apache Beam 2.4.0 has been released on March 20th.
>>>
>>> According to our cycle of release (roughly 6 weeks), we should think
>>> about 2.5.0.
>>>
>>> I'm volunteer to tackle this release.
>>>
>>> I'm proposing the following items:
>>>
>>> 1. We start the Jira triage now, up to Tuesday
>>> 2. I would like to cut the release on Tuesday night (Europe time)
>>> 2bis. I think it's wiser to still use Maven for this release. Do you
>>> think we
>>> will be ready to try a release with Gradle ?
>>>
>>> After this release, I would like a discussion about:
>>> 1. Gradle release (if we release 2.5.0 with Maven)
>>> 2. Isolate release cycle per Beam part. I think it would be
>>> interesting to have
>>> different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>> discussion, I
>>> will start a thread about that.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>
>>

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Ismaël Mejía
+1 to delay 2 weeks as Ahmet proposes. We can cut the branch in two
weeks in a more stable shape doing it right now is not a good idea.
We can justify the delay on the impact of transitioning the build system.


On Wed, Apr 11, 2018 at 10:35 PM, Ahmet Altay  wrote:
> +1 to delaying 2 weeks.
>
> I think it will be prudent to wait in this case. There is too much in flux
> with Gradle migration currently and based on Scott's latest update I think
> we will be in a more stable state in 2 weeks. Last Beam release date was
> 3/20 and our plan was to make a release every 6 weeks. Even if we start
> cutting a release in 2 weeks (~4/26), we will have more than a week to
> finish that release. Even if that is not enough time to finish a release it
> will put is in the proximity of the 5/5 target date. I prefer that option,
> to another potential release with Maven.
>
> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau 
> wrote:
>>
>> Any hope the release is on central before the 30th?
>
>
> I do not think this was the plan to begin with. The time between the
> previous release and 4/30 is less than 6 weeks.
>
>>
>>
>> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>>>
>>> +1 to keeping up the regular release cycle, but I don't think it makes
>>> sense to cut until we're ready to actively work on the release. A cut date
>>> two weeks from now seems fine (unless someone else is volunteering to do it
>>> this time around).
>>>
>>> That being said, a dry run using gradle now may make a lot of sense,
>>> giving us a couple of weeks to iron out the kinks, if any.
>>>
>>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath
>>>  wrote:

 Hi JB,

 Please note that I opened a blocker [1] (working on it) and looks like
 we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
 weeks (or till JIRAs are resolved or moved off the list).

 Thanks,
 Cham

 [1] https://issues.apache.org/jira/browse/BEAM-3991
 [2]
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC

 On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
 wrote:
>
> Hi guys,
>
> Due to the last work, I think it makes sense to try a release using
> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
> maybe in that case, we should ask ourselves if Gradle is really a good
> alternative for now.
>
> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
> tomorrow end of the morning (my time). But in the case we need some
> additional PR merges or we have some work in progress, I'm proposing to
> postpone 2.5.0 release for the end of this month (in two weeks). If
> someone is volunteer to tackle this release, please, let us know.
>
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> > about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> > think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be
> > interesting to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> > discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Ahmet Altay
+1 to delaying 2 weeks.

I think it will be prudent to wait in this case. There is too much in flux
with Gradle migration currently and based on Scott's latest update I think
we will be in a more stable state in 2 weeks. Last Beam release date was
3/20 and our plan was to make a release every 6 weeks. Even if we start
cutting a release in 2 weeks (~4/26), we will have more than a week to
finish that release. Even if that is not enough time to finish a release it
will put is in the proximity of the 5/5 target date. I prefer that option,
to another potential release with Maven.

On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau 
wrote:

> Any hope the release is on central before the 30th?
>

I do not think this was the plan to begin with. The time between the
previous release and 4/30 is less than 6 weeks.


>
> Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :
>
>> +1 to keeping up the regular release cycle, but I don't think it makes
>> sense to cut until we're ready to actively work on the release. A cut date
>> two weeks from now seems fine (unless someone else is volunteering to do it
>> this time around).
>>
>> That being said, a dry run using gradle now may make a lot of sense,
>> giving us a couple of weeks to iron out the kinks, if any.
>>
>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
>> wrote:
>>
>>> Hi JB,
>>>
>>> Please note that I opened a blocker [1] (working on it) and looks like
>>> we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
>>> weeks (or till JIRAs are resolved or moved off the list).
>>>
>>> Thanks,
>>> Cham
>>>
>>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>>> [2] https://issues.apache.org/jira/issues/?jql=project%20%3D
>>> %20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVer
>>> sion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>>
>>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
>>> wrote:
>>>
 Hi guys,

 Due to the last work, I think it makes sense to try a release using
 Gradle. If it doesn't work smoothly, we will rollback to Maven, and
 maybe in that case, we should ask ourselves if Gradle is really a good
 alternative for now.

 I'm in vacation tomorrow morning for 2 weeks. I can cut the release
 tomorrow end of the morning (my time). But in the case we need some
 additional PR merges or we have some work in progress, I'm proposing to
 postpone 2.5.0 release for the end of this month (in two weeks). If
 someone is volunteer to tackle this release, please, let us know.

 Regards
 JB

 On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
 > Hi guys,
 >
 > Apache Beam 2.4.0 has been released on March 20th.
 >
 > According to our cycle of release (roughly 6 weeks), we should think
 about 2.5.0.
 >
 > I'm volunteer to tackle this release.
 >
 > I'm proposing the following items:
 >
 > 1. We start the Jira triage now, up to Tuesday
 > 2. I would like to cut the release on Tuesday night (Europe time)
 > 2bis. I think it's wiser to still use Maven for this release. Do you
 think we
 > will be ready to try a release with Gradle ?
 >
 > After this release, I would like a discussion about:
 > 1. Gradle release (if we release 2.5.0 with Maven)
 > 2. Isolate release cycle per Beam part. I think it would be
 interesting to have
 > different release cycle: SDKs, DSLs, Runners, IOs. That's another
 discussion, I
 > will start a thread about that.
 >
 > Thoughts ?
 >
 > Regards
 > JB
 >

>>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Romain Manni-Bucau
Any hope the release is on central before the 30th?

Le 11 avr. 2018 22:02, "Robert Bradshaw"  a écrit :

> +1 to keeping up the regular release cycle, but I don't think it makes
> sense to cut until we're ready to actively work on the release. A cut date
> two weeks from now seems fine (unless someone else is volunteering to do it
> this time around).
>
> That being said, a dry run using gradle now may make a lot of sense,
> giving us a couple of weeks to iron out the kinks, if any.
>
> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
> wrote:
>
>> Hi JB,
>>
>> Please note that I opened a blocker [1] (working on it) and looks like we
>> have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
>> (or till JIRAs are resolved or moved off the list).
>>
>> Thanks,
>> Cham
>>
>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>> [2] https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%
>> 20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>
>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi guys,
>>>
>>> Due to the last work, I think it makes sense to try a release using
>>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>>> maybe in that case, we should ask ourselves if Gradle is really a good
>>> alternative for now.
>>>
>>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>>> tomorrow end of the morning (my time). But in the case we need some
>>> additional PR merges or we have some work in progress, I'm proposing to
>>> postpone 2.5.0 release for the end of this month (in two weeks). If
>>> someone is volunteer to tackle this release, please, let us know.
>>>
>>> Regards
>>> JB
>>>
>>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>> > Hi guys,
>>> >
>>> > Apache Beam 2.4.0 has been released on March 20th.
>>> >
>>> > According to our cycle of release (roughly 6 weeks), we should think
>>> about 2.5.0.
>>> >
>>> > I'm volunteer to tackle this release.
>>> >
>>> > I'm proposing the following items:
>>> >
>>> > 1. We start the Jira triage now, up to Tuesday
>>> > 2. I would like to cut the release on Tuesday night (Europe time)
>>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>>> think we
>>> > will be ready to try a release with Gradle ?
>>> >
>>> > After this release, I would like a discussion about:
>>> > 1. Gradle release (if we release 2.5.0 with Maven)
>>> > 2. Isolate release cycle per Beam part. I think it would be
>>> interesting to have
>>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>> discussion, I
>>> > will start a thread about that.
>>> >
>>> > Thoughts ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Robert Bradshaw
+1 to keeping up the regular release cycle, but I don't think it makes
sense to cut until we're ready to actively work on the release. A cut date
two weeks from now seems fine (unless someone else is volunteering to do it
this time around).

That being said, a dry run using gradle now may make a lot of sense, giving
us a couple of weeks to iron out the kinks, if any.

On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath 
wrote:

> Hi JB,
>
> Please note that I opened a blocker [1] (working on it) and looks like we
> have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
> (or till JIRAs are resolved or moved off the list).
>
> Thanks,
> Cham
>
> [1] https://issues.apache.org/jira/browse/BEAM-3991
> [2]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>
> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
> wrote:
>
>> Hi guys,
>>
>> Due to the last work, I think it makes sense to try a release using
>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>> maybe in that case, we should ask ourselves if Gradle is really a good
>> alternative for now.
>>
>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>> tomorrow end of the morning (my time). But in the case we need some
>> additional PR merges or we have some work in progress, I'm proposing to
>> postpone 2.5.0 release for the end of this month (in two weeks). If
>> someone is volunteer to tackle this release, please, let us know.
>>
>> Regards
>> JB
>>
>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>> > Hi guys,
>> >
>> > Apache Beam 2.4.0 has been released on March 20th.
>> >
>> > According to our cycle of release (roughly 6 weeks), we should think
>> about 2.5.0.
>> >
>> > I'm volunteer to tackle this release.
>> >
>> > I'm proposing the following items:
>> >
>> > 1. We start the Jira triage now, up to Tuesday
>> > 2. I would like to cut the release on Tuesday night (Europe time)
>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>> think we
>> > will be ready to try a release with Gradle ?
>> >
>> > After this release, I would like a discussion about:
>> > 1. Gradle release (if we release 2.5.0 with Maven)
>> > 2. Isolate release cycle per Beam part. I think it would be interesting
>> to have
>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> discussion, I
>> > will start a thread about that.
>> >
>> > Thoughts ?
>> >
>> > Regards
>> > JB
>> >
>>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Chamikara Jayalath
Hi JB,

Please note that I opened a blocker [1] (working on it) and looks like we
have several other JIRAs marked for 2.5.0. So +1 for waiting for two weeks
(or till JIRAs are resolved or moved off the list).

Thanks,
Cham

[1] https://issues.apache.org/jira/browse/BEAM-3991
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC

On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> Due to the last work, I think it makes sense to try a release using
> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
> maybe in that case, we should ask ourselves if Gradle is really a good
> alternative for now.
>
> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
> tomorrow end of the morning (my time). But in the case we need some
> additional PR merges or we have some work in progress, I'm proposing to
> postpone 2.5.0 release for the end of this month (in two weeks). If
> someone is volunteer to tackle this release, please, let us know.
>
> Regards
> JB
>
> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-11 Thread Jean-Baptiste Onofré

Hi guys,

Due to the last work, I think it makes sense to try a release using 
Gradle. If it doesn't work smoothly, we will rollback to Maven, and 
maybe in that case, we should ask ourselves if Gradle is really a good 
alternative for now.


I'm in vacation tomorrow morning for 2 weeks. I can cut the release 
tomorrow end of the morning (my time). But in the case we need some 
additional PR merges or we have some work in progress, I'm proposing to 
postpone 2.5.0 release for the end of this month (in two weeks). If 
someone is volunteer to tackle this release, please, let us know.


Regards
JB

On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:

Hi guys,

Apache Beam 2.4.0 has been released on March 20th.

According to our cycle of release (roughly 6 weeks), we should think about 
2.5.0.

I'm volunteer to tackle this release.

I'm proposing the following items:

1. We start the Jira triage now, up to Tuesday
2. I would like to cut the release on Tuesday night (Europe time)
2bis. I think it's wiser to still use Maven for this release. Do you think we
will be ready to try a release with Gradle ?

After this release, I would like a discussion about:
1. Gradle release (if we release 2.5.0 with Maven)
2. Isolate release cycle per Beam part. I think it would be interesting to have
different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, I
will start a thread about that.

Thoughts ?

Regards
JB



Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-10 Thread Lukasz Cwik
Nightly snapshots have migrated to being produced via Gradle. Alan Myrvold
and a few others have been working on adding automated tests that validate
those nightly snapshots by running through the quickstarts available on the
website.

Please try out the nightly snapshot and report bugs as sub-tasks underneath
BEAM-3249 related to dependency issues you find.

On Tue, Apr 10, 2018 at 8:43 AM Ismaël Mejía  wrote:

> +1000 to Romain's point on dependencies, we have to obsessively pay
> attention to the consistency of the dependencies, this is critical for
> users and we cannot radically change the produced artifacts or we risk
> of breaking their applications..
>
>
> On Tue, Apr 10, 2018 at 6:56 AM, Romain Manni-Bucau
>  wrote:
> > Yes, but I never saw anyone grabbing the sources from dist in maven world
> > but I did saw people using maven dependency plugin to grab the sources
> and
> > the pom and rebuild the modules. I'm not saying it is the best practise
> but
> > beam will always be maven for most java users so we must be very careful
> on
> > that.
> >
> > Personally i only nees dependencies to respect provided/compile/test
> scopes
> > (not shadow which corrupts a pom ;)).
> >
> > For the story jetbrains builds with gradle its plugin repository client
> and
> > uploads to bintray the same kind of pom that we have in the mentionned
> > branch (just gav, no dep etc). It is fully broken on consuler side and
> > requires users to just bypass the dependency management goodness and go
> to
> > the sources to find all the build constraints (java compatible version,
> > packagings, ...). This is why i mentionned that generating some build
> > plugins is important and that keeping profiles would not break consumers.
> >
> > Le 10 avr. 2018 05:34, "Jean-Baptiste Onofré"  a écrit
> :
> >>
> >> Hi Luke,
> >>
> >> you are right, from a Apache perspective, the only required artifacts is
> >> the
> >> source tarball on dist (that should be buildable).
> >>
> >> There is no requirement for the ones on Maven, it's more for convenience
> >> for our
> >> users.
> >>
> >> Regards
> >> JB
> >>
> >> On 04/09/2018 09:56 PM, Lukasz Cwik wrote:
> >> > Romain, I was under the impression that the source tar ball that is
> >> > uploaded to
> >> > www.apache.org/dist/  is required to be
> >> > buildable
> >> > and is a separate deliverable from the artifacts (jars
> >> > (source/test/javadoc/...)/poms) uploaded to
> >> > https://repository.apache.org/service/local/staging/deploy/maven2.
> >> >
> >> > The source tar ball uploaded to www.apache.org/dist/
> >> >  will contain the gradle build files
> >> > allowing one
> >> > to reproduce the artifacts (jars (source/test/javadoc)/poms).
> >> >
> >> > On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> > > wrote:
> >> >
> >> >
> >> >
> >> > Le 9 avr. 2018 16:06, "Lukasz Cwik"  >> > > a écrit :
> >> >
> >> >
> >> >
> >> > On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau
> >> > > wrote:
> >> >
> >> > I got the same with that PR applied and the previous
> >> > command. Is using
> >> > your fork needed?
> >> >
> >> > No, you can also use https://github.com/apache/beam/pull/5048
> >> >
> >> >
> >> > Is there any PR to import it?
> >> >
> >> > Yes, https://github.com/apache/beam/pull/5048
> >> >
> >> >
> >> >
> >> > Ok so it doesnt work and generates a pom without parent nor
> >> > dependencies
> >> > which is a bare minimum but not enough since exploding the sources
> >> > jar and
> >> > running the pom should build a valid jar.
> >> >
> >> >
> >> > In any case master is not ready to be released with that
> yet
> >> > - to come
> >> > back to the actual topic.
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >> >
> >> >
> >> > 2018-04-09 15:56 GMT+02:00 Lukasz Cwik  >> > >:
> >> > > Romain,
> >> > > The gradle based release process has an open PR in
> >> > > https://github.com/apache/beam/pull/5048 to merge to
> >> > master.
> >> > > I thought you were running the commands from
> >> > > https://github.com/lukecwik/incubator-beam/tree/gradle
> >> > >
> >> > > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau
> >> > >
> >> > > wrote:
> >> > >>
> >> > >> @Lukasz: same with gradlew and release option, pom is
> >> > empty (no
> >> > parent, no
> >> > >> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-10 Thread Ismaël Mejía
+1000 to Romain's point on dependencies, we have to obsessively pay
attention to the consistency of the dependencies, this is critical for
users and we cannot radically change the produced artifacts or we risk
of breaking their applications..


On Tue, Apr 10, 2018 at 6:56 AM, Romain Manni-Bucau
 wrote:
> Yes, but I never saw anyone grabbing the sources from dist in maven world
> but I did saw people using maven dependency plugin to grab the sources and
> the pom and rebuild the modules. I'm not saying it is the best practise but
> beam will always be maven for most java users so we must be very careful on
> that.
>
> Personally i only nees dependencies to respect provided/compile/test scopes
> (not shadow which corrupts a pom ;)).
>
> For the story jetbrains builds with gradle its plugin repository client and
> uploads to bintray the same kind of pom that we have in the mentionned
> branch (just gav, no dep etc). It is fully broken on consuler side and
> requires users to just bypass the dependency management goodness and go to
> the sources to find all the build constraints (java compatible version,
> packagings, ...). This is why i mentionned that generating some build
> plugins is important and that keeping profiles would not break consumers.
>
> Le 10 avr. 2018 05:34, "Jean-Baptiste Onofré"  a écrit :
>>
>> Hi Luke,
>>
>> you are right, from a Apache perspective, the only required artifacts is
>> the
>> source tarball on dist (that should be buildable).
>>
>> There is no requirement for the ones on Maven, it's more for convenience
>> for our
>> users.
>>
>> Regards
>> JB
>>
>> On 04/09/2018 09:56 PM, Lukasz Cwik wrote:
>> > Romain, I was under the impression that the source tar ball that is
>> > uploaded to
>> > www.apache.org/dist/  is required to be
>> > buildable
>> > and is a separate deliverable from the artifacts (jars
>> > (source/test/javadoc/...)/poms) uploaded to
>> > https://repository.apache.org/service/local/staging/deploy/maven2.
>> >
>> > The source tar ball uploaded to www.apache.org/dist/
>> >  will contain the gradle build files
>> > allowing one
>> > to reproduce the artifacts (jars (source/test/javadoc)/poms).
>> >
>> > On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau > > > wrote:
>> >
>> >
>> >
>> > Le 9 avr. 2018 16:06, "Lukasz Cwik" > > > a écrit :
>> >
>> >
>> >
>> > On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau
>> > > wrote:
>> >
>> > I got the same with that PR applied and the previous
>> > command. Is using
>> > your fork needed?
>> >
>> > No, you can also use https://github.com/apache/beam/pull/5048
>> >
>> >
>> > Is there any PR to import it?
>> >
>> > Yes, https://github.com/apache/beam/pull/5048
>> >
>> >
>> >
>> > Ok so it doesnt work and generates a pom without parent nor
>> > dependencies
>> > which is a bare minimum but not enough since exploding the sources
>> > jar and
>> > running the pom should build a valid jar.
>> >
>> >
>> > In any case master is not ready to be released with that yet
>> > - to come
>> > back to the actual topic.
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >
>> >
>> > 2018-04-09 15:56 GMT+02:00 Lukasz Cwik > > >:
>> > > Romain,
>> > > The gradle based release process has an open PR in
>> > > https://github.com/apache/beam/pull/5048 to merge to
>> > master.
>> > > I thought you were running the commands from
>> > > https://github.com/lukecwik/incubator-beam/tree/gradle
>> > >
>> > > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau
>> > >
>> > > wrote:
>> > >>
>> > >> @Lukasz: same with gradlew and release option, pom is
>> > empty (no
>> > parent, no
>> > >> dependencies, no more description - needed since central
>> > poms use
>> > that for
>> > >> doc purposes).
>> > >>
>> > >>
>> > >> Romain Manni-Bucau
>> > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn |
>> > Book
>> > >>
>> > >> 2018-04-09 15:00 GMT+02:00 Reuven Lax > > >:
>> > >>>
>> > >>> Is everything needed merged into master?
>> > >>>
>> > >>> If so, why don't we try doing it with Gradle, but "fail
>> > fast"
>> > back to
>> > >>> Maven if 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
Yes, but I never saw anyone grabbing the sources from dist in maven world
but I did saw people using maven dependency plugin to grab the sources and
the pom and rebuild the modules. I'm not saying it is the best practise but
beam will always be maven for most java users so we must be very careful on
that.

Personally i only nees dependencies to respect provided/compile/test scopes
(not shadow which corrupts a pom ;)).

For the story jetbrains builds with gradle its plugin repository client and
uploads to bintray the same kind of pom that we have in the mentionned
branch (just gav, no dep etc). It is fully broken on consuler side and
requires users to just bypass the dependency management goodness and go to
the sources to find all the build constraints (java compatible version,
packagings, ...). This is why i mentionned that generating some build
plugins is important and that keeping profiles would not break consumers.

Le 10 avr. 2018 05:34, "Jean-Baptiste Onofré"  a écrit :

> Hi Luke,
>
> you are right, from a Apache perspective, the only required artifacts is
> the
> source tarball on dist (that should be buildable).
>
> There is no requirement for the ones on Maven, it's more for convenience
> for our
> users.
>
> Regards
> JB
>
> On 04/09/2018 09:56 PM, Lukasz Cwik wrote:
> > Romain, I was under the impression that the source tar ball that is
> uploaded to
> > www.apache.org/dist/  is required to be
> buildable
> > and is a separate deliverable from the artifacts (jars
> > (source/test/javadoc/...)/poms) uploaded to
> > https://repository.apache.org/service/local/staging/deploy/maven2.
> >
> > The source tar ball uploaded to www.apache.org/dist/
> >  will contain the gradle build files
> allowing one
> > to reproduce the artifacts (jars (source/test/javadoc)/poms).
> >
> > On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau  > > wrote:
> >
> >
> >
> > Le 9 avr. 2018 16:06, "Lukasz Cwik"  > > a écrit :
> >
> >
> >
> > On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau
> > > wrote:
> >
> > I got the same with that PR applied and the previous
> command. Is using
> > your fork needed?
> >
> > No, you can also use https://github.com/apache/beam/pull/5048
> >
> >
> > Is there any PR to import it?
> >
> > Yes, https://github.com/apache/beam/pull/5048
> >
> >
> >
> > Ok so it doesnt work and generates a pom without parent nor
> dependencies
> > which is a bare minimum but not enough since exploding the sources
> jar and
> > running the pom should build a valid jar.
> >
> >
> > In any case master is not ready to be released with that yet
> - to come
> > back to the actual topic.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > 2018-04-09 15:56 GMT+02:00 Lukasz Cwik  > >:
> > > Romain,
> > > The gradle based release process has an open PR in
> > > https://github.com/apache/beam/pull/5048 to merge to
> master.
> > > I thought you were running the commands from
> > > https://github.com/lukecwik/incubator-beam/tree/gradle
> > >
> > > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau
> > >
> > > wrote:
> > >>
> > >> @Lukasz: same with gradlew and release option, pom is
> empty (no
> > parent, no
> > >> dependencies, no more description - needed since central
> poms use
> > that for
> > >> doc purposes).
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > >>
> > >> 2018-04-09 15:00 GMT+02:00 Reuven Lax  > >:
> > >>>
> > >>> Is everything needed merged into master?
> > >>>
> > >>> If so, why don't we try doing it with Gradle, but "fail
> fast"
> > back to
> > >>> Maven if something doesn't work. If something doesn't
> quite work
> > I don't
> > >>> think we should delay 2.5.0 while we fix it, when we can
> still
> > do 2.5.0 with
> > >>> Maven.
> > >>>
> > >>> Reuven
> > >>>
> > >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik <
> lc...@google.com
> > > wrote:
> > 
> >  I would rather have the 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Jean-Baptiste Onofré
Hi Luke,

you are right, from a Apache perspective, the only required artifacts is the
source tarball on dist (that should be buildable).

There is no requirement for the ones on Maven, it's more for convenience for our
users.

Regards
JB

On 04/09/2018 09:56 PM, Lukasz Cwik wrote:
> Romain, I was under the impression that the source tar ball that is uploaded 
> to
> www.apache.org/dist/  is required to be buildable
> and is a separate deliverable from the artifacts (jars
> (source/test/javadoc/...)/poms) uploaded to
> https://repository.apache.org/service/local/staging/deploy/maven2.
> 
> The source tar ball uploaded to www.apache.org/dist/
>  will contain the gradle build files allowing one
> to reproduce the artifacts (jars (source/test/javadoc)/poms).
> 
> On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau  > wrote:
> 
> 
> 
> Le 9 avr. 2018 16:06, "Lukasz Cwik"  > a écrit :
> 
> 
> 
> On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau
> > wrote:
> 
> I got the same with that PR applied and the previous command. Is 
> using
> your fork needed? 
> 
> No, you can also use https://github.com/apache/beam/pull/5048
>  
> 
> Is there any PR to import it?
> 
> Yes, https://github.com/apache/beam/pull/5048
> 
> 
> 
> Ok so it doesnt work and generates a pom without parent nor dependencies
> which is a bare minimum but not enough since exploding the sources jar and
> running the pom should build a valid jar.
> 
> 
> In any case master is not ready to be released with that yet - to 
> come
> back to the actual topic. 
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik  >:
> > Romain,
> > The gradle based release process has an open PR in
> > https://github.com/apache/beam/pull/5048 to merge to master.
> > I thought you were running the commands from
> > https://github.com/lukecwik/incubator-beam/tree/gradle
> >
> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau
> >
> > wrote:
> >>
> >> @Lukasz: same with gradlew and release option, pom is empty (no
> parent, no
> >> dependencies, no more description - needed since central poms 
> use
> that for
> >> doc purposes).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax  >:
> >>>
> >>> Is everything needed merged into master?
> >>>
> >>> If so, why don't we try doing it with Gradle, but "fail fast"
> back to
> >>> Maven if something doesn't work. If something doesn't quite 
> work
> I don't
> >>> think we should delay 2.5.0 while we fix it, when we can still
> do 2.5.0 with
> >>> Maven.
> >>>
> >>> Reuven
> >>>
> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  > wrote:
> 
>  I would rather have the community try doing the 2.5.0 
> release with
>  Gradle and to fix the issues while people are currently
> focusing on the
>  migration and not 6 weeks from now when the 2.6.0 release
> starts. We can
>  always fallback to Maven if the community thinks its not 
> ready.
> If we go
>  with using Gradle, we should wait till the docs get updated 
> so
> people
>  working on the release know how to do it.
> 
>  Romain, use `./gradlew publishToMavenLocal -Prelease` to
> publish the
>  release candidate version to Maven local.
> 
> 
> 
>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>  > wrote:
> >
> > Surely did something wrong launching: gradle [build]
> > publishToMavenLocal
> >
> >
> >
> > $ cat
> >
> 
> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Robert Bradshaw
+1 to trying the release with gradle for 2.5, falling back if it doesn't
work. We'd rather find issues sooner than later.

For newcommers, I don't know that our maven setup was any more
understandable than our gradle one, especially for those not already in the
Java world. I am somewhat split on the being explicit vs. being idiomatic
debate though.

Regarding the source release artifact, I don't think it should have the
poms, right? It should literally be "wget
https://github.com/apache/beam/archive/[release-commit].zip;

On Mon, Apr 9, 2018 at 12:56 PM Lukasz Cwik  wrote:

> Romain, I was under the impression that the source tar ball that is
> uploaded to www.apache.org/dist/ is required to be buildable and is a
> separate deliverable from the artifacts (jars
> (source/test/javadoc/...)/poms) uploaded to
> https://repository.apache.org/service/local/staging/deploy/maven2.
>
> The source tar ball uploaded to www.apache.org/dist/ will contain the
> gradle build files allowing one to reproduce the artifacts (jars
> (source/test/javadoc)/poms).
>
> On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau 
> wrote:
>
>>
>>
>> Le 9 avr. 2018 16:06, "Lukasz Cwik"  a écrit :
>>
>>
>>
>> On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau 
>> wrote:
>>
>>> I got the same with that PR applied and the previous command. Is using
>>> your fork needed?
>>
>> No, you can also use https://github.com/apache/beam/pull/5048
>>
>>
>>> Is there any PR to import it?
>>>
>> Yes, https://github.com/apache/beam/pull/5048
>>
>>
>>
>> Ok so it doesnt work and generates a pom without parent nor dependencies
>> which is a bare minimum but not enough since exploding the sources jar and
>> running the pom should build a valid jar.
>>
>>
>> In any case master is not ready to be released with that yet - to come
>>> back to the actual topic.
>>
>>
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>>
>>>
>>> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik :
>>> > Romain,
>>> > The gradle based release process has an open PR in
>>> > https://github.com/apache/beam/pull/5048 to merge to master.
>>> > I thought you were running the commands from
>>> > https://github.com/lukecwik/incubator-beam/tree/gradle
>>> >
>>> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>>> > wrote:
>>> >>
>>> >> @Lukasz: same with gradlew and release option, pom is empty (no
>>> parent, no
>>> >> dependencies, no more description - needed since central poms use
>>> that for
>>> >> doc purposes).
>>> >>
>>> >>
>>> >> Romain Manni-Bucau
>>> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> >>
>>> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
>>> >>>
>>> >>> Is everything needed merged into master?
>>> >>>
>>> >>> If so, why don't we try doing it with Gradle, but "fail fast" back to
>>> >>> Maven if something doesn't work. If something doesn't quite work I
>>> don't
>>> >>> think we should delay 2.5.0 while we fix it, when we can still do
>>> 2.5.0 with
>>> >>> Maven.
>>> >>>
>>> >>> Reuven
>>> >>>
>>> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik 
>>> wrote:
>>> 
>>>  I would rather have the community try doing the 2.5.0 release with
>>>  Gradle and to fix the issues while people are currently focusing on
>>> the
>>>  migration and not 6 weeks from now when the 2.6.0 release starts.
>>> We can
>>>  always fallback to Maven if the community thinks its not ready. If
>>> we go
>>>  with using Gradle, we should wait till the docs get updated so
>>> people
>>>  working on the release know how to do it.
>>> 
>>>  Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>>>  release candidate version to Maven local.
>>> 
>>> 
>>> 
>>>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>>>   wrote:
>>> >
>>> > Surely did something wrong launching: gradle [build]
>>> > publishToMavenLocal
>>> >
>>> >
>>> >
>>> > $ cat
>>> >
>>> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
>>> > 
>>> > http://maven.apache.org/POM/4.0.0;
>>> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> > http://maven.apache.org/xsd/maven-4.0.0.xsd;
>>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>>> >   4.0.0
>>> >   org.apache.beam
>>> >   beam-sdks-java-core
>>> >   2.5.0-SNAPSHOT
>>> >   Apache Beam :: SDKs :: Java :: Core
>>> > 
>>> >
>>> >
>>> > Doesn't seem that ready ;)
>>> >
>>> >
>>> >
>>> > Romain Manni-Bucau
>>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> >
>>> > 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
>>> >>
>>> >> I will check now what's 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Lukasz Cwik
Romain, I was under the impression that the source tar ball that is
uploaded to www.apache.org/dist/ is required to be buildable and is a
separate deliverable from the artifacts (jars
(source/test/javadoc/...)/poms) uploaded to
https://repository.apache.org/service/local/staging/deploy/maven2.

The source tar ball uploaded to www.apache.org/dist/ will contain the
gradle build files allowing one to reproduce the artifacts (jars
(source/test/javadoc)/poms).

On Mon, Apr 9, 2018 at 3:44 PM Romain Manni-Bucau 
wrote:

>
>
> Le 9 avr. 2018 16:06, "Lukasz Cwik"  a écrit :
>
>
>
> On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau 
> wrote:
>
>> I got the same with that PR applied and the previous command. Is using
>> your fork needed?
>
> No, you can also use https://github.com/apache/beam/pull/5048
>
>
>> Is there any PR to import it?
>>
> Yes, https://github.com/apache/beam/pull/5048
>
>
>
> Ok so it doesnt work and generates a pom without parent nor dependencies
> which is a bare minimum but not enough since exploding the sources jar and
> running the pom should build a valid jar.
>
>
> In any case master is not ready to be released with that yet - to come
>> back to the actual topic.
>
>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>
>>
>> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik :
>> > Romain,
>> > The gradle based release process has an open PR in
>> > https://github.com/apache/beam/pull/5048 to merge to master.
>> > I thought you were running the commands from
>> > https://github.com/lukecwik/incubator-beam/tree/gradle
>> >
>> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >>
>> >> @Lukasz: same with gradlew and release option, pom is empty (no
>> parent, no
>> >> dependencies, no more description - needed since central poms use that
>> for
>> >> doc purposes).
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >>
>> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
>> >>>
>> >>> Is everything needed merged into master?
>> >>>
>> >>> If so, why don't we try doing it with Gradle, but "fail fast" back to
>> >>> Maven if something doesn't work. If something doesn't quite work I
>> don't
>> >>> think we should delay 2.5.0 while we fix it, when we can still do
>> 2.5.0 with
>> >>> Maven.
>> >>>
>> >>> Reuven
>> >>>
>> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:
>> 
>>  I would rather have the community try doing the 2.5.0 release with
>>  Gradle and to fix the issues while people are currently focusing on
>> the
>>  migration and not 6 weeks from now when the 2.6.0 release starts. We
>> can
>>  always fallback to Maven if the community thinks its not ready. If
>> we go
>>  with using Gradle, we should wait till the docs get updated so people
>>  working on the release know how to do it.
>> 
>>  Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>>  release candidate version to Maven local.
>> 
>> 
>> 
>>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>>   wrote:
>> >
>> > Surely did something wrong launching: gradle [build]
>> > publishToMavenLocal
>> >
>> >
>> >
>> > $ cat
>> >
>> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
>> > 
>> > http://maven.apache.org/POM/4.0.0;
>> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> > http://maven.apache.org/xsd/maven-4.0.0.xsd;
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>> >   4.0.0
>> >   org.apache.beam
>> >   beam-sdks-java-core
>> >   2.5.0-SNAPSHOT
>> >   Apache Beam :: SDKs :: Java :: Core
>> > 
>> >
>> >
>> > Doesn't seem that ready ;)
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >
>> > 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >>
>> >> I will check now what's the pom status, if they are ok it can be
>> worth
>> >> testing gradle
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >>
>> >> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>> >>>
>> >>> Hi Reuven,
>> >>>
>> >>> that was on of the question. I proposed to stay with Maven for
>> 2.5.0
>> >>> and switch
>> >>> to Gradle to 2.6.0 (in order for us to stabilize gradle build).
>> But,
>> >>> it may
>> >>> worth to try 2.5.0 with Gradle.
>> >>>
>> >>> Regards
>> >>> JB
>> >>>
>> >>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
>> >>> > To the folks working on Gradle last week - are we at 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
Le 9 avr. 2018 16:06, "Lukasz Cwik"  a écrit :



On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau 
wrote:

> I got the same with that PR applied and the previous command. Is using
> your fork needed?

No, you can also use https://github.com/apache/beam/pull/5048


> Is there any PR to import it?
>
Yes, https://github.com/apache/beam/pull/5048



Ok so it doesnt work and generates a pom without parent nor dependencies
which is a bare minimum but not enough since exploding the sources jar and
running the pom should build a valid jar.


In any case master is not ready to be released with that yet - to come
> back to the actual topic.


> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik :
> > Romain,
> > The gradle based release process has an open PR in
> > https://github.com/apache/beam/pull/5048 to merge to master.
> > I thought you were running the commands from
> > https://github.com/lukecwik/incubator-beam/tree/gradle
> >
> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau  >
> > wrote:
> >>
> >> @Lukasz: same with gradlew and release option, pom is empty (no parent,
> no
> >> dependencies, no more description - needed since central poms use that
> for
> >> doc purposes).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
> >>>
> >>> Is everything needed merged into master?
> >>>
> >>> If so, why don't we try doing it with Gradle, but "fail fast" back to
> >>> Maven if something doesn't work. If something doesn't quite work I
> don't
> >>> think we should delay 2.5.0 while we fix it, when we can still do
> 2.5.0 with
> >>> Maven.
> >>>
> >>> Reuven
> >>>
> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:
> 
>  I would rather have the community try doing the 2.5.0 release with
>  Gradle and to fix the issues while people are currently focusing on
> the
>  migration and not 6 weeks from now when the 2.6.0 release starts. We
> can
>  always fallback to Maven if the community thinks its not ready. If we
> go
>  with using Gradle, we should wait till the docs get updated so people
>  working on the release know how to do it.
> 
>  Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>  release candidate version to Maven local.
> 
> 
> 
>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>   wrote:
> >
> > Surely did something wrong launching: gradle [build]
> > publishToMavenLocal
> >
> >
> >
> > $ cat
> > ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.
> 0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
> > 
> > http://maven.apache.org/POM/4.0.0;
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> >   4.0.0
> >   org.apache.beam
> >   beam-sdks-java-core
> >   2.5.0-SNAPSHOT
> >   Apache Beam :: SDKs :: Java :: Core
> > 
> >
> >
> > Doesn't seem that ready ;)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> > 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau  >:
> >>
> >> I will check now what's the pom status, if they are ok it can be
> worth
> >> testing gradle
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
> >>>
> >>> Hi Reuven,
> >>>
> >>> that was on of the question. I proposed to stay with Maven for
> 2.5.0
> >>> and switch
> >>> to Gradle to 2.6.0 (in order for us to stabilize gradle build).
> But,
> >>> it may
> >>> worth to try 2.5.0 with Gradle.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
> >>> > To the folks working on Gradle last week - are we at the point
> >>> > where we can try
> >>> > running this release purely using Gradle, or should we wait until
> >>> > 2.6.0?
> >>> >
> >>> > Reuven
> >>> >
> >>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré
> >>> >  >>> > > wrote:
> >>> >
> >>> > Up ?
> >>> >
> >>> > Regards
> >>> > JB
> >>> >
> >>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> >>> > > Hi guys,
> >>> > >
> >>> > > Apache Beam 2.4.0 has been released on March 20th.
> >>> > >
> >>> > > According to our cycle of release (roughly 6 weeks), we
> 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Jean-Baptiste Onofré
On testing on the PR branch.

Regards
JB

On 04/09/2018 04:06 PM, Lukasz Cwik wrote:
> 
> 
> On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau  > wrote:
> 
> I got the same with that PR applied and the previous command. Is using
> your fork needed? 
> 
> No, you can also use https://github.com/apache/beam/pull/5048
>  
> 
> Is there any PR to import it?
> 
> Yes, https://github.com/apache/beam/pull/5048
> 
> In any case master is not ready to be released with that yet - to come
> back to the actual topic. 
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik  >:
> > Romain,
> > The gradle based release process has an open PR in
> > https://github.com/apache/beam/pull/5048 to merge to master.
> > I thought you were running the commands from
> > https://github.com/lukecwik/incubator-beam/tree/gradle
> >
> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau  >
> > wrote:
> >>
> >> @Lukasz: same with gradlew and release option, pom is empty (no 
> parent, no
> >> dependencies, no more description - needed since central poms use that 
> for
> >> doc purposes).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax  >:
> >>>
> >>> Is everything needed merged into master?
> >>>
> >>> If so, why don't we try doing it with Gradle, but "fail fast" back to
> >>> Maven if something doesn't work. If something doesn't quite work I 
> don't
> >>> think we should delay 2.5.0 while we fix it, when we can still do 
> 2.5.0 with
> >>> Maven.
> >>>
> >>> Reuven
> >>>
> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  > wrote:
> 
>  I would rather have the community try doing the 2.5.0 release with
>  Gradle and to fix the issues while people are currently focusing on 
> the
>  migration and not 6 weeks from now when the 2.6.0 release starts. We 
> can
>  always fallback to Maven if the community thinks its not ready. If 
> we go
>  with using Gradle, we should wait till the docs get updated so people
>  working on the release know how to do it.
> 
>  Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>  release candidate version to Maven local.
> 
> 
> 
>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>  > wrote:
> >
> > Surely did something wrong launching: gradle [build]
> > publishToMavenLocal
> >
> >
> >
> > $ cat
> >
> 
> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
> > 
> > http://maven.apache.org/POM/4.0.0;
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> >   4.0.0
> >   org.apache.beam
> >   beam-sdks-java-core
> >   2.5.0-SNAPSHOT
> >   Apache Beam :: SDKs :: Java :: Core
> > 
> >
> >
> > Doesn't seem that ready ;)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> > 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau  >:
> >>
> >> I will check now what's the pom status, if they are ok it can be 
> worth
> >> testing gradle
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré  >:
> >>>
> >>> Hi Reuven,
> >>>
> >>> that was on of the question. I proposed to stay with Maven for 
> 2.5.0
> >>> and switch
> >>> to Gradle to 2.6.0 (in order for us to stabilize gradle build). 
> But,
> >>> it may
> >>> worth to try 2.5.0 with Gradle.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
> >>> > To the folks working on Gradle last week - are we at the point
> >>> > where we can try
> >>> > running this release purely using Gradle, or should we wait 
> until
> >>> > 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Lukasz Cwik
On Mon, Apr 9, 2018 at 10:02 AM Romain Manni-Bucau 
wrote:

> I got the same with that PR applied and the previous command. Is using
> your fork needed?

No, you can also use https://github.com/apache/beam/pull/5048


> Is there any PR to import it?
>
Yes, https://github.com/apache/beam/pull/5048

In any case master is not ready to be released with that yet - to come
> back to the actual topic.


> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-09 15:56 GMT+02:00 Lukasz Cwik :
> > Romain,
> > The gradle based release process has an open PR in
> > https://github.com/apache/beam/pull/5048 to merge to master.
> > I thought you were running the commands from
> > https://github.com/lukecwik/incubator-beam/tree/gradle
> >
> > On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau  >
> > wrote:
> >>
> >> @Lukasz: same with gradlew and release option, pom is empty (no parent,
> no
> >> dependencies, no more description - needed since central poms use that
> for
> >> doc purposes).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
> >>>
> >>> Is everything needed merged into master?
> >>>
> >>> If so, why don't we try doing it with Gradle, but "fail fast" back to
> >>> Maven if something doesn't work. If something doesn't quite work I
> don't
> >>> think we should delay 2.5.0 while we fix it, when we can still do
> 2.5.0 with
> >>> Maven.
> >>>
> >>> Reuven
> >>>
> >>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:
> 
>  I would rather have the community try doing the 2.5.0 release with
>  Gradle and to fix the issues while people are currently focusing on
> the
>  migration and not 6 weeks from now when the 2.6.0 release starts. We
> can
>  always fallback to Maven if the community thinks its not ready. If we
> go
>  with using Gradle, we should wait till the docs get updated so people
>  working on the release know how to do it.
> 
>  Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>  release candidate version to Maven local.
> 
> 
> 
>  On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
>   wrote:
> >
> > Surely did something wrong launching: gradle [build]
> > publishToMavenLocal
> >
> >
> >
> > $ cat
> >
> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
> > 
> > http://maven.apache.org/POM/4.0.0;
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> >   4.0.0
> >   org.apache.beam
> >   beam-sdks-java-core
> >   2.5.0-SNAPSHOT
> >   Apache Beam :: SDKs :: Java :: Core
> > 
> >
> >
> > Doesn't seem that ready ;)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> > 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau  >:
> >>
> >> I will check now what's the pom status, if they are ok it can be
> worth
> >> testing gradle
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
> >>>
> >>> Hi Reuven,
> >>>
> >>> that was on of the question. I proposed to stay with Maven for
> 2.5.0
> >>> and switch
> >>> to Gradle to 2.6.0 (in order for us to stabilize gradle build).
> But,
> >>> it may
> >>> worth to try 2.5.0 with Gradle.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
> >>> > To the folks working on Gradle last week - are we at the point
> >>> > where we can try
> >>> > running this release purely using Gradle, or should we wait until
> >>> > 2.6.0?
> >>> >
> >>> > Reuven
> >>> >
> >>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré
> >>> >  >>> > > wrote:
> >>> >
> >>> > Up ?
> >>> >
> >>> > Regards
> >>> > JB
> >>> >
> >>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> >>> > > Hi guys,
> >>> > >
> >>> > > Apache Beam 2.4.0 has been released on March 20th.
> >>> > >
> >>> > > According to our cycle of release (roughly 6 weeks), we
> >>> > should think about
> >>> > 2.5.0.
> >>> > >
> >>> > > I'm volunteer to tackle this release.
> >>> > >
> >>> > > I'm proposing the following items:
> >>> > >
> >>> > > 1. We start the Jira triage now, 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
I got the same with that PR applied and the previous command. Is using
your fork needed? Is there any PR to import it?
In any case master is not ready to be released with that yet - to come
back to the actual topic.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


2018-04-09 15:56 GMT+02:00 Lukasz Cwik :
> Romain,
> The gradle based release process has an open PR in
> https://github.com/apache/beam/pull/5048 to merge to master.
> I thought you were running the commands from
> https://github.com/lukecwik/incubator-beam/tree/gradle
>
> On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau 
> wrote:
>>
>> @Lukasz: same with gradlew and release option, pom is empty (no parent, no
>> dependencies, no more description - needed since central poms use that for
>> doc purposes).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>
>> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
>>>
>>> Is everything needed merged into master?
>>>
>>> If so, why don't we try doing it with Gradle, but "fail fast" back to
>>> Maven if something doesn't work. If something doesn't quite work I don't
>>> think we should delay 2.5.0 while we fix it, when we can still do 2.5.0 with
>>> Maven.
>>>
>>> Reuven
>>>
>>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:

 I would rather have the community try doing the 2.5.0 release with
 Gradle and to fix the issues while people are currently focusing on the
 migration and not 6 weeks from now when the 2.6.0 release starts. We can
 always fallback to Maven if the community thinks its not ready. If we go
 with using Gradle, we should wait till the docs get updated so people
 working on the release know how to do it.

 Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
 release candidate version to Maven local.



 On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau
  wrote:
>
> Surely did something wrong launching: gradle [build]
> publishToMavenLocal
>
>
>
> $ cat
> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
> 
> http://maven.apache.org/POM/4.0.0;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>   4.0.0
>   org.apache.beam
>   beam-sdks-java-core
>   2.5.0-SNAPSHOT
>   Apache Beam :: SDKs :: Java :: Core
> 
>
>
> Doesn't seem that ready ;)
>
>
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
> 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :
>>
>> I will check now what's the pom status, if they are ok it can be worth
>> testing gradle
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>
>> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>>>
>>> Hi Reuven,
>>>
>>> that was on of the question. I proposed to stay with Maven for 2.5.0
>>> and switch
>>> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But,
>>> it may
>>> worth to try 2.5.0 with Gradle.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
>>> > To the folks working on Gradle last week - are we at the point
>>> > where we can try
>>> > running this release purely using Gradle, or should we wait until
>>> > 2.6.0?
>>> >
>>> > Reuven
>>> >
>>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré
>>> > >> > > wrote:
>>> >
>>> > Up ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>>> > > Hi guys,
>>> > >
>>> > > Apache Beam 2.4.0 has been released on March 20th.
>>> > >
>>> > > According to our cycle of release (roughly 6 weeks), we
>>> > should think about
>>> > 2.5.0.
>>> > >
>>> > > I'm volunteer to tackle this release.
>>> > >
>>> > > I'm proposing the following items:
>>> > >
>>> > > 1. We start the Jira triage now, up to Tuesday
>>> > > 2. I would like to cut the release on Tuesday night (Europe
>>> > time)
>>> > > 2bis. I think it's wiser to still use Maven for this release.
>>> > Do you think we
>>> > > will be ready to try a release with Gradle ?
>>> > >
>>> > > After this release, I would like a discussion about:
>>> > > 1. Gradle release (if we release 2.5.0 with Maven)
>>> > > 2. Isolate release cycle per Beam part. I think it 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Lukasz Cwik
Romain,
The gradle based release process has an open PR in
https://github.com/apache/beam/pull/5048 to merge to master.
I thought you were running the commands from
https://github.com/lukecwik/incubator-beam/tree/gradle

On Mon, Apr 9, 2018 at 9:13 AM Romain Manni-Bucau 
wrote:

> @Lukasz: same with gradlew and release option, pom is empty (no parent,
> no dependencies, no more description - needed since central poms use that
> for doc purposes).
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-04-09 15:00 GMT+02:00 Reuven Lax :
>
>> Is everything needed merged into master?
>>
>> If so, why don't we try doing it with Gradle, but "fail fast" back to
>> Maven if something doesn't work. If something doesn't quite work I don't
>> think we should delay 2.5.0 while we fix it, when we can still do 2.5.0
>> with Maven.
>>
>> Reuven
>>
>> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:
>>
>>> I would rather have the community try doing the 2.5.0 release with
>>> Gradle and to fix the issues while people are currently focusing on the
>>> migration and not 6 weeks from now when the 2.6.0 release starts. We can
>>> always fallback to Maven if the community thinks its not ready. If we go
>>> with using Gradle, we should wait till the docs get updated so people
>>> working on the release know how to do it.
>>>
>>> Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>>> release candidate version to Maven local.
>>>
>>>
>>>
>>> On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau 
>>> wrote:
>>>
 Surely did something wrong launching: gradle [build] publishToMavenLocal



 $ cat
 ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
 
 http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="
 http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns:xsi="
 http://www.w3.org/2001/XMLSchema-instance;>
   4.0.0
   org.apache.beam
   beam-sdks-java-core
   2.5.0-SNAPSHOT
   Apache Beam :: SDKs :: Java :: Core
 


 Doesn't seem that ready ;)



 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book
 

 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :

> I will check now what's the pom status, if they are ok it can be worth
> testing gradle
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>
>> Hi Reuven,
>>
>> that was on of the question. I proposed to stay with Maven for 2.5.0
>> and switch
>> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But,
>> it may
>> worth to try 2.5.0 with Gradle.
>>
>> Regards
>> JB
>>
>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
>> > To the folks working on Gradle last week - are we at the point
>> where we can try
>> > running this release purely using Gradle, or should we wait until
>> 2.6.0?
>> >
>> > Reuven
>> >
>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré <
>> j...@nanthrax.net
>> > > wrote:
>> >
>> > Up ?
>> >
>> > Regards
>> > JB
>> >
>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>> > > Hi guys,
>> > >
>> > > Apache Beam 2.4.0 has been released on March 20th.
>> > >
>> > > According to our cycle of release (roughly 6 weeks), we
>> should think about
>> > 2.5.0.
>> > >
>> > > I'm volunteer to tackle this release.
>> > >
>> > > I'm proposing the following items:
>> > >
>> > > 1. We start the Jira triage now, up to Tuesday
>> > > 2. I would like to cut the release on Tuesday night (Europe
>> time)
>> > > 2bis. I think it's wiser to still use 

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
@Lukasz: same with gradlew and release option, pom is empty (no parent, no
dependencies, no more description - needed since central poms use that for
doc purposes).


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-09 15:00 GMT+02:00 Reuven Lax :

> Is everything needed merged into master?
>
> If so, why don't we try doing it with Gradle, but "fail fast" back to
> Maven if something doesn't work. If something doesn't quite work I don't
> think we should delay 2.5.0 while we fix it, when we can still do 2.5.0
> with Maven.
>
> Reuven
>
> On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:
>
>> I would rather have the community try doing the 2.5.0 release with Gradle
>> and to fix the issues while people are currently focusing on the migration
>> and not 6 weeks from now when the 2.6.0 release starts. We can always
>> fallback to Maven if the community thinks its not ready. If we go with
>> using Gradle, we should wait till the docs get updated so people working on
>> the release know how to do it.
>>
>> Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
>> release candidate version to Maven local.
>>
>>
>>
>> On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau 
>> wrote:
>>
>>> Surely did something wrong launching: gradle [build] publishToMavenLocal
>>>
>>>
>>>
>>> $ cat ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.
>>> 0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
>>> 
>>> http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="
>>> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/
>>> maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>>>   4.0.0
>>>   org.apache.beam
>>>   beam-sdks-java-core
>>>   2.5.0-SNAPSHOT
>>>   Apache Beam :: SDKs :: Java :: Core
>>> 
>>>
>>>
>>> Doesn't seem that ready ;)
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>> 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :
>>>
 I will check now what's the pom status, if they are ok it can be worth
 testing gradle


 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book
 

 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :

> Hi Reuven,
>
> that was on of the question. I proposed to stay with Maven for 2.5.0
> and switch
> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But,
> it may
> worth to try 2.5.0 with Gradle.
>
> Regards
> JB
>
> On 04/09/2018 02:27 PM, Reuven Lax wrote:
> > To the folks working on Gradle last week - are we at the point where
> we can try
> > running this release purely using Gradle, or should we wait until
> 2.6.0?
> >
> > Reuven
> >
> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré  > > wrote:
> >
> > Up ?
> >
> > Regards
> > JB
> >
> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release (roughly 6 weeks), we should
> think about
> > 2.5.0.
> > >
> > > I'm volunteer to tackle this release.
> > >
> > > I'm proposing the following items:
> > >
> > > 1. We start the Jira triage now, up to Tuesday
> > > 2. I would like to cut the release on Tuesday night (Europe
> time)
> > > 2bis. I think it's wiser to still use Maven for this release.
> Do you think we
> > > will be ready to try a release with Gradle ?
> > >
> > > After this release, I would like a discussion about:
> > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > 2. Isolate release cycle per Beam part. I think it would be
> interesting to
> > have
> > > different release cycle: SDKs, DSLs, Runners, IOs. That's
> another
> >   

Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Reuven Lax
Is everything needed merged into master?

If so, why don't we try doing it with Gradle, but "fail fast" back to Maven
if something doesn't work. If something doesn't quite work I don't think we
should delay 2.5.0 while we fix it, when we can still do 2.5.0 with Maven.

Reuven

On Mon, Apr 9, 2018 at 12:58 PM Lukasz Cwik  wrote:

> I would rather have the community try doing the 2.5.0 release with Gradle
> and to fix the issues while people are currently focusing on the migration
> and not 6 weeks from now when the 2.6.0 release starts. We can always
> fallback to Maven if the community thinks its not ready. If we go with
> using Gradle, we should wait till the docs get updated so people working on
> the release know how to do it.
>
> Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
> release candidate version to Maven local.
>
>
>
> On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau 
> wrote:
>
>> Surely did something wrong launching: gradle [build] publishToMavenLocal
>>
>>
>>
>> $ cat
>> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
>> 
>> http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance;>
>>   4.0.0
>>   org.apache.beam
>>   beam-sdks-java-core
>>   2.5.0-SNAPSHOT
>>   Apache Beam :: SDKs :: Java :: Core
>> 
>>
>>
>> Doesn't seem that ready ;)
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>> 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :
>>
>>> I will check now what's the pom status, if they are ok it can be worth
>>> testing gradle
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>>>
 Hi Reuven,

 that was on of the question. I proposed to stay with Maven for 2.5.0
 and switch
 to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it
 may
 worth to try 2.5.0 with Gradle.

 Regards
 JB

 On 04/09/2018 02:27 PM, Reuven Lax wrote:
 > To the folks working on Gradle last week - are we at the point where
 we can try
 > running this release purely using Gradle, or should we wait until
 2.6.0?
 >
 > Reuven
 >
 > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré  > wrote:
 >
 > Up ?
 >
 > Regards
 > JB
 >
 > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
 > > Hi guys,
 > >
 > > Apache Beam 2.4.0 has been released on March 20th.
 > >
 > > According to our cycle of release (roughly 6 weeks), we should
 think about
 > 2.5.0.
 > >
 > > I'm volunteer to tackle this release.
 > >
 > > I'm proposing the following items:
 > >
 > > 1. We start the Jira triage now, up to Tuesday
 > > 2. I would like to cut the release on Tuesday night (Europe
 time)
 > > 2bis. I think it's wiser to still use Maven for this release.
 Do you think we
 > > will be ready to try a release with Gradle ?
 > >
 > > After this release, I would like a discussion about:
 > > 1. Gradle release (if we release 2.5.0 with Maven)
 > > 2. Isolate release cycle per Beam part. I think it would be
 interesting to
 > have
 > > different release cycle: SDKs, DSLs, Runners, IOs. That's
 another
 > discussion, I
 > > will start a thread about that.
 > >
 > > Thoughts ?
 > >
 > > Regards
 > > JB
 > >
 >
 > --
 > Jean-Baptiste Onofré
 > jbono...@apache.org 
 > http://blog.nanthrax.net
 > Talend - http://www.talend.com
 >

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

>>>
>>>
>>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Lukasz Cwik
I would rather have the community try doing the 2.5.0 release with Gradle
and to fix the issues while people are currently focusing on the migration
and not 6 weeks from now when the 2.6.0 release starts. We can always
fallback to Maven if the community thinks its not ready. If we go with
using Gradle, we should wait till the docs get updated so people working on
the release know how to do it.

Romain, use `./gradlew publishToMavenLocal -Prelease` to publish the
release candidate version to Maven local.



On Mon, Apr 9, 2018 at 8:47 AM Romain Manni-Bucau 
wrote:

> Surely did something wrong launching: gradle [build] publishToMavenLocal
>
>
>
> $ cat
> ~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom
> 
> http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;>
>   4.0.0
>   org.apache.beam
>   beam-sdks-java-core
>   2.5.0-SNAPSHOT
>   Apache Beam :: SDKs :: Java :: Core
> 
>
>
> Doesn't seem that ready ;)
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :
>
>> I will check now what's the pom status, if they are ok it can be worth
>> testing gradle
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>>
>>> Hi Reuven,
>>>
>>> that was on of the question. I proposed to stay with Maven for 2.5.0 and
>>> switch
>>> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it
>>> may
>>> worth to try 2.5.0 with Gradle.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
>>> > To the folks working on Gradle last week - are we at the point where
>>> we can try
>>> > running this release purely using Gradle, or should we wait until
>>> 2.6.0?
>>> >
>>> > Reuven
>>> >
>>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré >> > > wrote:
>>> >
>>> > Up ?
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>>> > > Hi guys,
>>> > >
>>> > > Apache Beam 2.4.0 has been released on March 20th.
>>> > >
>>> > > According to our cycle of release (roughly 6 weeks), we should
>>> think about
>>> > 2.5.0.
>>> > >
>>> > > I'm volunteer to tackle this release.
>>> > >
>>> > > I'm proposing the following items:
>>> > >
>>> > > 1. We start the Jira triage now, up to Tuesday
>>> > > 2. I would like to cut the release on Tuesday night (Europe time)
>>> > > 2bis. I think it's wiser to still use Maven for this release. Do
>>> you think we
>>> > > will be ready to try a release with Gradle ?
>>> > >
>>> > > After this release, I would like a discussion about:
>>> > > 1. Gradle release (if we release 2.5.0 with Maven)
>>> > > 2. Isolate release cycle per Beam part. I think it would be
>>> interesting to
>>> > have
>>> > > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>> > discussion, I
>>> > > will start a thread about that.
>>> > >
>>> > > Thoughts ?
>>> > >
>>> > > Regards
>>> > > JB
>>> > >
>>> >
>>> > --
>>> > Jean-Baptiste Onofré
>>> > jbono...@apache.org 
>>> > http://blog.nanthrax.net
>>> > Talend - http://www.talend.com
>>> >
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
Surely did something wrong launching: gradle [build] publishToMavenLocal



$ cat
~/.m2/repository/org/apache/beam/beam-sdks-java-core/2.5.0-SNAPSHOT/beam-sdks-java-core-2.5.0-SNAPSHOT.pom

http://maven.apache.org/POM/4.0.0; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;>
  4.0.0
  org.apache.beam
  beam-sdks-java-core
  2.5.0-SNAPSHOT
  Apache Beam :: SDKs :: Java :: Core



Doesn't seem that ready ;)



Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-09 14:38 GMT+02:00 Romain Manni-Bucau :

> I will check now what's the pom status, if they are ok it can be worth
> testing gradle
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :
>
>> Hi Reuven,
>>
>> that was on of the question. I proposed to stay with Maven for 2.5.0 and
>> switch
>> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it
>> may
>> worth to try 2.5.0 with Gradle.
>>
>> Regards
>> JB
>>
>> On 04/09/2018 02:27 PM, Reuven Lax wrote:
>> > To the folks working on Gradle last week - are we at the point where we
>> can try
>> > running this release purely using Gradle, or should we wait until 2.6.0?
>> >
>> > Reuven
>> >
>> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré > > > wrote:
>> >
>> > Up ?
>> >
>> > Regards
>> > JB
>> >
>> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
>> > > Hi guys,
>> > >
>> > > Apache Beam 2.4.0 has been released on March 20th.
>> > >
>> > > According to our cycle of release (roughly 6 weeks), we should
>> think about
>> > 2.5.0.
>> > >
>> > > I'm volunteer to tackle this release.
>> > >
>> > > I'm proposing the following items:
>> > >
>> > > 1. We start the Jira triage now, up to Tuesday
>> > > 2. I would like to cut the release on Tuesday night (Europe time)
>> > > 2bis. I think it's wiser to still use Maven for this release. Do
>> you think we
>> > > will be ready to try a release with Gradle ?
>> > >
>> > > After this release, I would like a discussion about:
>> > > 1. Gradle release (if we release 2.5.0 with Maven)
>> > > 2. Isolate release cycle per Beam part. I think it would be
>> interesting to
>> > have
>> > > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>> > discussion, I
>> > > will start a thread about that.
>> > >
>> > > Thoughts ?
>> > >
>> > > Regards
>> > > JB
>> > >
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbono...@apache.org 
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Romain Manni-Bucau
I will check now what's the pom status, if they are ok it can be worth
testing gradle


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-09 14:36 GMT+02:00 Jean-Baptiste Onofré :

> Hi Reuven,
>
> that was on of the question. I proposed to stay with Maven for 2.5.0 and
> switch
> to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it may
> worth to try 2.5.0 with Gradle.
>
> Regards
> JB
>
> On 04/09/2018 02:27 PM, Reuven Lax wrote:
> > To the folks working on Gradle last week - are we at the point where we
> can try
> > running this release purely using Gradle, or should we wait until 2.6.0?
> >
> > Reuven
> >
> > On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré  > > wrote:
> >
> > Up ?
> >
> > Regards
> > JB
> >
> > On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > Apache Beam 2.4.0 has been released on March 20th.
> > >
> > > According to our cycle of release (roughly 6 weeks), we should
> think about
> > 2.5.0.
> > >
> > > I'm volunteer to tackle this release.
> > >
> > > I'm proposing the following items:
> > >
> > > 1. We start the Jira triage now, up to Tuesday
> > > 2. I would like to cut the release on Tuesday night (Europe time)
> > > 2bis. I think it's wiser to still use Maven for this release. Do
> you think we
> > > will be ready to try a release with Gradle ?
> > >
> > > After this release, I would like a discussion about:
> > > 1. Gradle release (if we release 2.5.0 with Maven)
> > > 2. Isolate release cycle per Beam part. I think it would be
> interesting to
> > have
> > > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> > discussion, I
> > > will start a thread about that.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org 
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Jean-Baptiste Onofré
Hi Reuven,

that was on of the question. I proposed to stay with Maven for 2.5.0 and switch
to Gradle to 2.6.0 (in order for us to stabilize gradle build). But, it may
worth to try 2.5.0 with Gradle.

Regards
JB

On 04/09/2018 02:27 PM, Reuven Lax wrote:
> To the folks working on Gradle last week - are we at the point where we can 
> try
> running this release purely using Gradle, or should we wait until 2.6.0?
> 
> Reuven
> 
> On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré  > wrote:
> 
> Up ?
> 
> Regards
> JB
> 
> On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think 
> about
> 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you 
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting 
> to
> have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Reuven Lax
To the folks working on Gradle last week - are we at the point where we can
try running this release purely using Gradle, or should we wait until 2.6.0?

Reuven

On Mon, Apr 9, 2018 at 8:01 AM Jean-Baptiste Onofré  wrote:

> Up ?
>
> Regards
> JB
>
> On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > Apache Beam 2.4.0 has been released on March 20th.
> >
> > According to our cycle of release (roughly 6 weeks), we should think
> about 2.5.0.
> >
> > I'm volunteer to tackle this release.
> >
> > I'm proposing the following items:
> >
> > 1. We start the Jira triage now, up to Tuesday
> > 2. I would like to cut the release on Tuesday night (Europe time)
> > 2bis. I think it's wiser to still use Maven for this release. Do you
> think we
> > will be ready to try a release with Gradle ?
> >
> > After this release, I would like a discussion about:
> > 1. Gradle release (if we release 2.5.0 with Maven)
> > 2. Isolate release cycle per Beam part. I think it would be interesting
> to have
> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> > will start a thread about that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-09 Thread Jean-Baptiste Onofré
Up ?

Regards
JB

On 04/06/2018 10:48 AM, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> Apache Beam 2.4.0 has been released on March 20th.
> 
> According to our cycle of release (roughly 6 weeks), we should think about 
> 2.5.0.
> 
> I'm volunteer to tackle this release.
> 
> I'm proposing the following items:
> 
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you think we
> will be ready to try a release with Gradle ?
> 
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be interesting to 
> have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another discussion, 
> I
> will start a thread about that.
> 
> Thoughts ?
> 
> Regards
> JB
> 

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


Re: [PROPOSAL] Preparing 2.5.0 release next week

2018-04-06 Thread Romain Manni-Bucau
+1 to get 2.5 out asap (fixes blockers so always good to let it be upgraded)
+1000 to split beam releases (and even repos) by concerns


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-04-06 10:48 GMT+02:00 Jean-Baptiste Onofré :

> Hi guys,
>
> Apache Beam 2.4.0 has been released on March 20th.
>
> According to our cycle of release (roughly 6 weeks), we should think about
> 2.5.0.
>
> I'm volunteer to tackle this release.
>
> I'm proposing the following items:
>
> 1. We start the Jira triage now, up to Tuesday
> 2. I would like to cut the release on Tuesday night (Europe time)
> 2bis. I think it's wiser to still use Maven for this release. Do you think
> we
> will be ready to try a release with Gradle ?
>
> After this release, I would like a discussion about:
> 1. Gradle release (if we release 2.5.0 with Maven)
> 2. Isolate release cycle per Beam part. I think it would be interesting to
> have
> different release cycle: SDKs, DSLs, Runners, IOs. That's another
> discussion, I
> will start a thread about that.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>