Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

Hi all, The vote started last Friday, and today we mark 4 days of boring time. With that in mind, I'm excited to announce that we have unanimously approved this release. There are 7 approving votes, 3 of which are binding: * Ahmet Altay * Jean-Baptiste Onofré * Reuven Lax There are no

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

I'll vote +1 as well. On Tue, Aug 7, 2018, 10:27 AM Reuven Lax wrote: > +1 (binding) > > On Tue, Aug 7, 2018 at 9:57 AM Pablo Estrada wrote: > >> Hello all, >> the voting seems to be going well for RC2. As a heads up for anyone to >> express concerns or questions, I will start wrapping up by

Re: Apache Beam Python Wheels Repository

Hey Pablo, For windows, I think Travis doesn't have a plan coming soon. But Matthew Brett's build scripts actually supports windows platform in Appveyor , which we doesn't have chance to explore more. Boyuan On Tue, Aug 7,

Re: Apache Beam Python Wheels Repository

Hi Boyuan, I think this is reasonable. I remember Robert supported this approach as well, and it is quite simple to support this. I am +1 on this. Do you know at all if there are any plans from Travis to support windows? Best -P. On Tue, Aug 7, 2018 at 2:04 PM Boyuan Zhang wrote: > Thanks for

Re: [Call for items] Beam August Newsletter

*nudge* Just a reminder to add your highlights to share with the community soon! If you're worried about how to phrase it or the format, just put down the info and I'll edit. Looking forward to reading your updates. :D On Thu, Aug 2, 2018 at 6:41 PM Pablo Estrada wrote: > Thanks for doing

Re: Apache Beam Python Wheels Repository

Thanks for Davor's suggestions. Following content discusses more about why we need a new repository. Hope they would be helpful! Purpose of this proposal - Facilitate building python wheels against multi-os Why a new repository is needed - Currently we chose Matthew Brett's build scripts

Re: [DISCUSSION] Tracking & Visualizing various metrics of the Beam community

Thanks Udi, I am working on spinning up a test instance. On Tue, Aug 7, 2018 at 11:31 AM Udi Meiri wrote: > These tables look very cool! > > I certainly don't object to using tools made by another organization. The > only issue might be compatibility with our process. > > From my understanding

Re: Sorting in runners

Thanks! I will try to figure why GSC is disallowed and share it if I find anything. -Rui On Tue, Aug 7, 2018 at 12:00 PM Lukasz Cwik wrote: > IMO, going with SortValues is the right way to go. The idea is that > runners can always replace the SortValues PTransform with their own > optimized

Re: Sorting in runners

IMO, going with SortValues is the right way to go. The idea is that runners can always replace the SortValues PTransform with their own optimized variant. As you have already pointed out, the default inmemory implementation has strict limitations. I would suggest going with the inmemory version

Re: [DISCUSSION] Tracking & Visualizing various metrics of the Beam community

These tables look very cool! I certainly don't object to using tools made by another organization. The only issue might be compatibility with our process. >From my understanding of the Kubernetes review process, they use Github's tagging feature to specify PR statuses such as LGTM and approval.

Re: [DISCUSSION] Tracking & Visualizing various metrics of the Beam community

tl;dr - is there any objections to trying out DevStats tool created by CNCF? On Mon, Aug 6, 2018 at 3:43 PM Huygaa Batsaikhan wrote: > Continuing the discussion > > about

Sorting in runners

Hi Community, I am trying to support ORDER BY in BeamSQL (currently in global window only, see BEAM-5064). In order to do so, I need to sort PCollection. The scale of dataset that ORDER BY works on is unknown. It might be up to TB sized dataset if BeamSQL runs on some benchmarks. But in the most

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

+1 (binding) On Tue, Aug 7, 2018 at 9:57 AM Pablo Estrada wrote: > Hello all, > the voting seems to be going well for RC2. As a heads up for anyone to > express concerns or questions, I will start wrapping up by end-of-day today. > > I've run Google-internal Python precommit tests, which

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

Hello all, the voting seems to be going well for RC2. As a heads up for anyone to express concerns or questions, I will start wrapping up by end-of-day today. I've run Google-internal Python precommit tests, which involve running a few pipelines. Best -P. On Tue, Aug 7, 2018 at 9:03 AM Boyuan

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

Hey Valentyn, If you look into 2.5.0 python wheels, we didn't build wheels on Windows either: https://dist.apache.org/repos/dist/dev/beam/2.5.0/python/, since currently travis doesn't support windows os. Boyuan On Tue, Aug 7, 2018 at 8:46 AM Valentyn Tymofieiev wrote: > +1 (non-binding). > >

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

+1 (non-binding). I verified Python quick start on Direct & Dataflow runners on Windows, and a streaming wordcount pipeline on Linux. I noticed wheel files have ".rc2" suffix in their names, which was not the case for 2.5.0 but was also the case for 2.4.0. So I assume that's harmless. I also

Re: [VOTE] Apache Beam, version 2.6.0, release candidate #2

+1 (binding) Thank you. On Mon, Aug 6, 2018 at 4:21 PM, Boyuan Zhang wrote: > +1 non-binding > Verified dataflow items listed in https://s.apache.org/beam- > release-validation > > On Sun, Aug 5, 2018 at 6:37 AM Suneel Marthi wrote: > >> +1 non-binding >> >> 1. verified Sigs and Hashes of

Build failed in Jenkins: beam_Release_Gradle_NightlySnapshot #134

See Changes: [holden] Directly call Fn since we're wrapped anyways in plan.go [amaliujia] remove RelCollationTraitDef [github] [BEAM-4276] Combiner lifting for Dataflow [github] Add missing