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

You can see it differently: is there a critical bug? Yes! Is there a regression? No! So no need to wait another week (keep in mind 2 days + 3 days of vote makes easily 1 working week). This vote could be closed already and next week 2.2.1 could fix this bug, no? Overall idea is to not hold the com

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

-1 (binding) I agree with Eugene, data loss is severe. As Eugene seems confident to fix that quickly, I think it's worth to cut a RC4. However, I would introduce a deadline. As I would like to propose a release cycle of a release every 6 weeks (whatever it contains, but it really important to

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

We are trying our best. Unfortunately I agree with Eugene - releasing a known data-loss bug (even if it's only in one "feature") should not be acceptable. Hopefully we can fix this by Monday though. On Fri, Nov 10, 2017 at 5:50 PM, Ted Yu wrote: > Considering that the holiday is around the corne

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

Considering that the holiday is around the corner, it would be nice to release 2.2.0 sooner.  Cheers  Original message From: Chamikara Jayalath Date: 11/10/17 12:22 PM (GMT-08:00) To: dev@beam.apache.org Subject: Re: [VOTE] Release 2.2.0, release candidate #3 We found anothe

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

For the second issue, I'm just waiting for the tests to pass to merge. After that will send out a PR to cherry pick. So this should not delay the release by more than few hours. Not sure about the first issue. But given that it's a data loss I would like to get that fix in as well. Thanks, Cham O

Re: [DISCUSS] Move away from Apache Maven as build tool

This is only a setup thing and better to not break the master history for poc/tests, in particular when no very localized. Alternative can be to ask another temp repo to infra and have a synchro between both but dont think it does worth it personally. Le 10 nov. 2017 18:57, "Lukasz Cwik" a écri

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

Both issues are particular cases. Can the 2.2.0 be out and a 2.2.1 done quickly after? Would be very appreciated to have the 2.2.0 fixes to not depend on snapshots anymore due to some blockers found in the core of previous releases. Le 10 nov. 2017 21:23, "Chamikara Jayalath" a écrit : > We fou

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

We found another issue that should probably be fixed in 2.2.0 release: https://issues.apache.org/jira/browse/BEAM-3172 A fix is out for review and will be merged soon. Thanks, Cham On Fri, Nov 10, 2017 at 10:43 AM Eugene Kirpichov wrote: > Unfortunately I think I found a data loss bug - it was

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

Unfortunately I think I found a data loss bug - it was there since 2.0.0 but I think it's serious enough that delaying a fix until the next release would be irresponsible. See https://issues.apache.org/jira/browse/BEAM-3169 On Thu, Nov 9, 2017 at 3:57 PM Robert Bradshaw wrote: > Our release note

Re: [DISCUSS] Move away from Apache Maven as build tool

The reason to get it on master is because that is where all the PRs are. An upstream branch without any development means no data. Also, our Jenkins setup via job-dsl doesn't honor using the Jenkins configuration on the branch because the seed job always runs against master. On Thu, Nov 9, 2017 at

Re: [Proposal] Add performance tests for commonly used file-based I/O PTransforms

Thanks for the update. I will take a look. Regards JB On 11/10/2017 11:43 AM, Kamil Szewczyk wrote: We updated Step #2 in our proposal. Comments and suggestions are highly appreciated. Thanks 2017-10-31 15:42 GMT+01:00 Łukasz Gajowy : We edited the "Roadmap" section a little bit to reflect

Re: [Proposal] Add performance tests for commonly used file-based I/O PTransforms

We updated Step #2 in our proposal. Comments and suggestions are highly appreciated. Thanks 2017-10-31 15:42 GMT+01:00 Łukasz Gajowy : > We edited the "Roadmap" section a little bit to reflect our state of > knowledge. As before, all comments are welcome. > > Thank you in advance! > > 2017-10-27

Re: [VOTE] Drop Spark 1.x support to focus on Spark 2.x

I think so ;) Regards JB On 11/10/2017 09:29 AM, Reuven Lax wrote: Sounds good. I doubt we will have much opposition from users, in which case Beam 2.3.0 can deprecate Spark 1.x On Thu, Nov 9, 2017 at 11:54 PM, Jean-Baptiste Onofré wrote: Hi all, thanks a lot for all your feedback. The tr

Re: [VOTE] Drop Spark 1.x support to focus on Spark 2.x

Sounds good. I doubt we will have much opposition from users, in which case Beam 2.3.0 can deprecate Spark 1.x On Thu, Nov 9, 2017 at 11:54 PM, Jean-Baptiste Onofré wrote: > Hi all, > > thanks a lot for all your feedback. > > The trend is about to upgrade to Spark 2.x and drop Spark 1.x support.

Jenkins build is back to stable : beam_Release_NightlySnapshot #589

See