Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

I think it would be a "good to have" point (maybe not a blocker). I will propose a release guide PR about this tomorrow. Regards JB Le 1 mars 2018 à 09:09, à 09:09, Lukasz Cwik a écrit: >Should we change release policy so that the validation tests are >required >to pass on a

Re: Beam 2.4.0

About BEAM-3409, I did a review yesterday and it looks good to me. We are waiting for Thomas' feedback. Regards JB Le 1 mars 2018 à 09:38, à 09:38, Robert Bradshaw a écrit: >Looking at the burn-down list, we have 5 remaining issues. None of >these >are blockers, but all

Re: Beam 2.4.0

Looking at the burn-down list, we have 5 remaining issues. None of these are blockers, but all look like they're really close (reviewed, review comments were addressed, waiting for a final LGTM). Specifically: BEAM-3409 (teardown issues): Thomas Groh had some concerns, could you verify they have

Re: Beam 2.4.0

I tend to fall into the "release early, release often" camp in general, but for this one I'm particularly anxious to get the faster Python direct runner out in the hands of TFT/TFX users (and in particular have an eye on https://www.tensorflow.org/dev-summit/ which I think can be a healthy source

Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

Should we change release policy so that the validation tests are required to pass on a release candidate as a requirement for the release to be approved? If so, we should update the release guide saying so. On Wed, Feb 28, 2018 at 7:00 PM, Jean-Baptiste Onofré wrote: > Cool,

Re: Beam 2.4.0

Hi Gus, Thanks for the update, it makes sense. Regards JB On 03/01/2018 02:59 AM, Konstantinos Katsiapis wrote: > Hi Jean-Baptiste, > > I can speak from the perspective of tf.transform >  (TFT) in particular and TFX >

Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

Cool, thanks ! Maybe at least a note to run nexmark on every RC to compare the results with previous releases is interesting. Regards JB On 03/01/2018 02:02 AM, Alan Myrvold wrote: > Thanks for the feedback.  Yifan and I have automated the Java quickstarts for > apex, direct, dataflow, flink

Re: Beam 2.4.0

Hi Jean-Baptiste, I can speak from the perspective of tf.transform (TFT) in particular and TFX libs in general, in case it is useful. TFX distributed computation has 2 "large" dependencies, namely

Re: Instructions to install Python SDK from source

Hi Pablo, You have a great point. Getting started instructions for developers for Python SDK is not well documented. Installing Python SDK from source is a subset of this lack of documentation. There is a JIRA for this ( https://issues.apache.org/jira/browse/BEAM-3075). It would be great if you

Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

Thanks for the feedback. Yifan and I have automated the Java quickstarts for apex, direct, dataflow, flink local and spark [1] and automated python release validation [2]. Yifan is working on fixing the Java mobile archetype and validating the mobile example. The spark quickstart automation came

Instructions to install Python SDK from source

Hello all, I noticed that the README for Beam has some basic instructions on installing Beam from source using mvn. Do these instructions work also to install Python SDK? I have my own script to install the Python SDK from source reliably, but I recently noticed that there's no instructions to

Re: Python 3 flake 8: splitting up on the errors?

Awesome, I'll get that kicked off in JIRA On Feb 28, 2018 2:43 PM, "Ahmet Altay" wrote: > I think this is a great idea. I would encourage everyone who would like to > help with Python 3 migration to help with this effort. Holden, if you > already have a list, could you either

Re: Python 3 flake 8: splitting up on the errors?

I think this is a great idea. I would encourage everyone who would like to help with Python 3 migration to help with this effort. Holden, if you already have a list, could you either share the list or create individual JIRAs so that we can track the work among us. On Tue, Feb 27, 2018 at 4:53 PM,

Re: Proposed improvements to our documentation

Thanks for all the feedback. I have filed a JIRA [1] to get started. https://issues.apache.org/jira/browse/BEAM-3763 On Wed, Feb 28, 2018 at 12:11 PM Reuven Lax wrote: > +1 - to many things are documented only in Javadoc. While there are some > users who are more likely to

Re: github reviews weirdness

Yeah, I noticed the same thing. It's confusing. On Tue, Feb 27, 2018 at 11:56 PM Romain Manni-Bucau wrote: > Seems you are right Charles, not sure why it happens but found another > place with the exact same content but with writable inputs. Thanks a lot! > > > Romain

Re: Proposed improvements to our documentation

+1 - to many things are documented only in Javadoc. While there are some users who are more likely to read Javadoc (e.g. via an IDE), we should try and have this part of our public documentation. This will help us document the other languages as well. I've noticed that some basic things (e.g. how

Re: Proposed improvements to our documentation

+1 sounds reasonable. A couple more areas where our documentation could use some work: - I'm feeling very strongly that the documentation of windowing/triggers is due for a complete rewrite. It was written when Beam was first being revealed to the world, and now we have both extensive experience

Re: Proposed improvements to our documentation

+1 A per-transform reference will definitely help Python (and Go ?) since some transforms lack detailed documentation compared to Java. Additionally it might be a good idea to compare Java/Py/Go docs in general to make sure there are no inconsistencies. - Cham On Wed, Feb 28, 2018 at 10:53 AM

Re: Proposed improvements to our documentation

+1 I think this is a great idea, it can also serve as an inventory of where a language might be lacking in transforms and provide a good starting point for new contributors to fill in those gaps by looking at the existing Java implementations. On Wed, Feb 28, 2018 at 10:53 AM, Lukasz Cwik

Re: Proposed improvements to our documentation

Yes! I love the idea of having a good cross-language transform reference on the web site. Very good idea to get started now and provide the skeleton, then fill out additional transforms and additional languages incrementally. Kenn On Wed, Feb 28, 2018 at 10:23 AM, Rafael Fernandez

Proposed improvements to our documentation

Hi folks, I think we've all seen a few areas of improvement here and there in our docs. For example, one can find a a Javadoc entry with outdated content here and there [1], or "sample" code snippets that have problems, such as not compiling [2]. I think a good thing to do is to invest in

Re: Pain points in the 2.3.0 release / improvements to 2.4.0 release process?

Validating the release by following quickstarts being a manual process I believe is still the largest pain point: * We missed that the archetypes were missing the mobile gaming examples. * The tcnative dependency conflict that we needed to cut RC2 for. Overall much smoother then the prior release