Re: [ANNOUCEMENT] New Foundation members!

Congratulations! On Tue, Apr 3, 2018 at 10:31 AM Daniel Oliveira wrote: > Congrats! > > On Tue, Apr 3, 2018 at 2:05 AM Etienne Chauchot > wrote: > >> Congrats >> Le mardi 03 avril 2018 à 10:41 +0200, Kostas Kloudas a écrit : >> >> Congratulations

Re: Merge options in Github UI are confusing

I agree with Robert. In this case one size does not fit all. There are times, another round trip with a contributor would be frustrating to the author. Especially for new contributors. Having the option to squash and merge is useful in those cases. (For reference in the past we even helped new

Gradle Status [April 17th]

Gradle migration continues. Our last update was on April 13th, and since then there has been significant progress: Release artifacts: * Upgrade to latest Gradle PR5104 * Remove evaluationDependsOn and use shaded test jars PR5117 * Nightly java snapshot release fixed by PR5136 and PR 5142 and now

Re: Inconsistent jenkins workers

Sounds good, thanks for the update. And thanks especially to Pablo for pushing https://github.com/apache/beam/pull/5149 through in the meantime. On Mon, Apr 16, 2018 at 4:38 PM Yifan Zou wrote: > Thanks Jason for explanation. I am working on Jenkins containerization and

Re: Merge options in Github UI are confusing

I think the two options are useful, because we have different kinds of contributors. Sophisticated users curate their own history, create logically useful commits, build atop it, etc. and merge is by far the better option. Others have a single commit followed by any number of "lint," "fixup," and

Re: [PROPOSAL] Python 3 support

Kanban board for python 3: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=245 (Thank you Davor!) Ahmet On Fri, Apr 6, 2018 at 6:32 PM, Reuven Lax wrote: > I had a similar problem. > > On Fri, Apr 6, 2018, 6:23 PM Ahmet Altay wrote: > >> I

Re: Node Errors ("Backing Channel... is Disconnected.")

The Gradle build is much more granular in its ability to execute tasks in parallel, so it's possible that it's doing more parallel work and thus using additional memory. When I run a Gradle build locally with the same flags as Jenkins [1], I see a main Java process using ~2GB of memory and lots

Re: Merge options in Github UI are confusing

Not strongly against `*Create a merge commit*`, but I use `squash and merge` by default. I understand the potential impact mentioned by Andrew, it's still a better option IMO: 1. if a PR contains several parts, it can be documented in commit message instead of several commits; --If it's a big

Re: Merge options in Github UI are confusing

+1 Having made a few web commits and been frustrated by the options, anything to standardize on a single option seems good to me. On Tue, 17 Apr 2018 at 01:49 Etienne Chauchot wrote: > +1 to enforce the behavior recommended in the committer guide. I usually > ask the

Re: [Go SDK] Proposal: Set up a Vanity Import Path

This seems like a valuable layer of indirection to establish. The mechanisms are pretty esoteric, but I trust Gophers to know the best way to do it. Commented just a smidgin on the doc. Kenn On Mon, Apr 16, 2018 at 4:57 PM Robert Burke wrote: > Hi All! > While the Go SDK is

Re: Updated [Proposal] Apache Beam Fn API : Defining and adding SDK Metrics

That sounds like a very reasonable choice -- given the discussion seemed to be focusing on the differences between these two categories, separating them will allow the proposal (and implementation) to address each category in the best way possible without needing to make compromises. Looking

Re: Updated [Proposal] Apache Beam Fn API : Defining and adding SDK Metrics

Hello, I just wanted to give an update . After some discussion, I've realized that its best to break up the two concepts, with two separate way of reporting monitoring data. These two categories are: 1. Metrics - Counters, Gauges, Distributions. These are well defined concepts for

Re: Rebuilding beam before running Performance Test - question.

ok, fyi I created a PR for this here: https://github.com/apache/beam/pull/5153 2018-04-16 19:40 GMT+02:00 Jason Kuster : > I think that should be fine; I believe the way it was that way originally > was because we already had things set up for building in Jenkins, but it

Re: Performance tests status and anomaly detection proposal

Thanks for reviewing it. When operating on average there should also be presented standard deviation. Higher deviation means that we have more distributed and extreme results results and lower deviation value means that results are closer the average. It will indicate that tests are going more

Re: Merge options in Github UI are confusing

+1 to enforce the behavior recommended in the committer guide. I usually ask the author to manually squash before committing. Etienne Le lundi 16 avril 2018 à 22:19 +, Robert Bradshaw a écrit : > +1, though I'll admit I've been an occasional user of the "squash and merge" > button when a