Re: 0.1.0-incubating release

Out of curiosity, is there a reason for distributing the release on repository.a.o vs. dist.a.o? In my experience repository.a.o has traditionally been used for maven artifacts, and dist.a.o has been for release artifacts (source archives and convenience binaries). I'd be happy to help with

Re: 0.1.0-incubating release

Aljoscha, if you want to be sure and want only one RC like me, I'd suggest you search general incubator mail archive and look for comments from Justin & Sebb - they are very thorough and will give you a headstart instead of iterating multiple times. On Tue, Jun 7, 2016 at 12:59 PM Jean-Baptiste

Re: 0.1.0-incubating release

By the way, is there any document where we keep track of what checks to run for a release? Maybe I missed something, there. On Tue, 7 Jun 2016 at 21:29 Jean-Baptiste Onofré wrote: > Just submitted: https://github.com/apache/incubator-beam/pull/428 > > to fix the src

Re: 0.1.0-incubating release

I have to revert my vote to -1: the source distribution zip file is empty. I gonna submit a new PR to fix that. Sorry about that. Regards JB On 06/07/2016 09:12 PM, Jean-Baptiste Onofré wrote: +1 it looks good to me: - all files have incubating - signatures check out (asc, md5, sha1) (and

Re: 0.1.0-incubating release

+1 it looks good to me: - all files have incubating - signatures check out (asc, md5, sha1) (and KEYS there) - disclaimer exists - LICENSE and NOTICE good - No unexpected binary in source - All ASF licensed files have ASF headers - Source distribution is available, with a correct name, and

DoFn Reuse

Hey everyone; I'm starting to work on BEAM-38 ( https://issues.apache.org/jira/browse/BEAM-38), which enables an optimization for runners with many small bundles. BEAM-38 allows runners to reuse DoFn instances so long as that DoFn has not terminated abnormally. This replaces the previous

Re: One more streaming engine in OSS

Here's a writeup I did on Heron. http://www.jesse-anderson.com/2016/06/the-case-for-heron/ @nitin are you going to write a Concord runner? On Tue, Jun 7, 2016 at 12:37 PM Nitin Lamba wrote: > It gets better: > http://concord.io > > :) > > On Tue, Jun 7, 2016 at 9:28 AM, Dan

Re: One more streaming engine in OSS

It gets better: http://concord.io :) On Tue, Jun 7, 2016 at 9:28 AM, Dan Halperin wrote: > Yep! Without having done any analysis of Heron itself, I'd say that we'd > love to have a Beam-on-Heron runner as well! > > On Wed, May 25, 2016 at 2:30 PM, Seetharam

Re: 0.1.0-incubating release

+1 Lovely. Very readable. The "-parent" artifacts are just leaked implementation details of our build configuration that no one should ever actually reference, right? Kenn On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin wrote: > +2! This seems most concordant with

Re: One more streaming engine in OSS

Yep! Without having done any analysis of Heron itself, I'd say that we'd love to have a Beam-on-Heron runner as well! On Wed, May 25, 2016 at 2:30 PM, Seetharam Venkatesh < venkat...@innerzeal.com> wrote: > https://blog.twitter.com/2016/open-sourcing-twitter-heron > > More the merrier for Beam?

Re: 0.1.0-incubating release

+1 On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin wrote: > +2! This seems most concordant with other Apache products and the most > future-proof. > > On Mon, Jun 6, 2016 at 9:35 PM, Jean-Baptiste Onofré > wrote: > > > +1 > > > > Regards > > JB > >