Re: Add a (temporary) Portable Flink branch to the ASF repo?

I think we're actually quite safe in merging this into master because it doesn't really touch the currently existing Flink Runner. The "Portable Flink Runner" is essentially a new Runner that reuses some of the existing code and runtime components but doesn't modify them. What do you think? >

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

This seems like enough consensus to file the JIRA, so https://issues.apache.org/jira/browse/BEAM-4115 has now been created. I'll get to work on the PRs shortly. Cheers, Robert Burke On Wed, 18 Apr 2018 at 03:52 Jean-Baptiste Onofré wrote: > +1 > > Agree > Regards > JB > Le

Re: [PROPOSAL] Preparing 2.5.0 release next week

We have been generating a maven project using the archetype from gradle built snapshot releases and running the quickstarts using maven. Are there other interesting tests to try that the quickstarts miss? On Thu, Apr 12, 2018 at 9:21 AM Kenneth Knowles wrote: > Just because I

Re: Add a (temporary) Portable Flink branch to the ASF repo?

+1 to bring this to ASF repo ASAP. Also +1 to Aljoscha's idea if we can guarantee no interference. An extra branch has the issue of rebasing that will be 'automatically' solved if the development continues in master. Also other it will be easier to more contributors to jump in. On Wed, Apr 18,

Re: [PROPOSAL] Python 3 support

Robbe, I added you as a contributor to our JIRA. You should be able to assign issues to yourself. Board will auto update itself based on the issues. Give it a try. On Wed, Apr 18, 2018 at 1:15 AM, Robbe Sneyders wrote: > Thanks! > > Can someone give me permission to

[BEAM-4088] Test isolation differences in Gradle

I wanted to provide some additional information about this issue and Gradle test configuration. For context, BEAM-4088 [1] refers to a new test on PR/4965 [2] which verifies that no threads are being leaked. Under Maven the test passes, but under Gradle it reports leaked threads [3]. I'm not

Re: [BEAM-4088] Test isolation differences in Gradle

Le 18 avr. 2018 18:53, "Scott Wegner" a écrit : I wanted to provide some additional information about this issue and Gradle test configuration. For context, BEAM-4088 [1] refers to a new test on PR/4965 [2] which verifies that no threads are being leaked. Under Maven the

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

+1 Agree Regards JB Le 18 avr. 2018 à 14:51, à 14:51, Aljoscha Krettek a écrit: >+1 this sounds super reasonable > > >> On 17. Apr 2018, at 20:11, Kenneth Knowles wrote: >> >> This seems like a valuable layer of indirection to establish. The >mechanisms

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

+1 this sounds super reasonable > On 17. Apr 2018, at 20:11, Kenneth Knowles wrote: > > 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

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

That's good to know! I had heard of that specific rule, but I didn't realized it pertained to filing of a JIRA issue (when related to a proposal) as well. Thank you. On Wed, 18 Apr 2018 at 13:08 Ismaël Mejía wrote: > +1 Nice idea and proposal. > > This was not a vote thread

Re: [BEAM-4088] Test isolation differences in Gradle

The leaking threadq are already dumped but we dont track who created it Le 18 avr. 2018 22:50, "Kenneth Knowles" a écrit : > For this particular test, is it failing because a different test class > leaked threads? Is there a way to make something like a testing base class >

Re: [BEAM-4088] Test isolation differences in Gradle

For this particular test, is it failing because a different test class leaked threads? Is there a way to make something like a testing base class with @Before and @After actions that would catch the leak closer to where it happened? A quick search found this:

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

Well it is not really a rule for a proposal but notice that there are people in different time zones or people that for different reasons cannot answer immediately, so a longer period could give them a chance to voice their opinions. On Wed, Apr 18, 2018 at 10:23 PM, Robert Burke

Re: Merge options in Github UI are confusing

One thing that is available is the "allow maintainers to edit" which can let any committer push to the PR and do all of this. It is either on by default, or I have simply checked it in the past, since I have recently had a maintainer push to my PR on accident :-) On Tue, Apr 17, 2018 at 5:57 PM

Jenkins build is back to normal : beam_SeedJob #1523

See

Re: [PROPOSAL] Preparing 2.5.0 release next week

Most criticla pending issues to test before a gradle based release is that those generated poms are equal to the maven ones. Which means that they don't add by mistake compile dependencies where they were not. It is also critical to validate that all the meta-info is generated as it was done with

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

+1 Nice idea and proposal. This was not a vote thread but for the future it is a good idea to let a bigger time window before reaching consensus. Notice that a formal vote lets at least 72h for participants to voice their opinion before concluding something.

Re: [PROPOSAL] JIRA notification recipient changes

commits@ or dev@ are common choices. Others are generally redundant or means it is ignored by everybody which is fine but means you just drop notif from jira instead of redirecting them ;) Just my 2 cts Le 18 avr. 2018 20:55, "Kenneth Knowles" a écrit : > Annoyingly, it

Re: [PROPOSAL] JIRA notification recipient changes

Annoyingly, it appears that the reporter is not automatically a watcher. It is incorrect that it is a strict degradation, but I agree that it is not a good change to make since it favors devs over users. I will chat with infra about whether we can set up the best case. In the meantime, perhaps

Build failed in Jenkins: beam_SeedJob #1522

See -- GitHub pull request #5170 of commit f39ac0bf0f392c9ed42a43e655698b55d10c2b54, no merge conflicts. Setting status of f39ac0bf0f392c9ed42a43e655698b55d10c2b54 to PENDING with url

Re: Build failed in Jenkins: beam_SeedJob #1522

FYI: I was adding new job to jenkins and got some groovy parsing error. https://github.com/apache/beam/pull/5170. No worries, I will take a look at this later. 2018-04-18 21:36 GMT+02:00 Apache Jenkins Server : > See

Re: [PROPOSAL] Python 3 support

Thanks! Can someone give me permission to assign issues to myself? And edit rights to the Kanban board? Robbe On Tue, 17 Apr 2018 at 22:56 Ahmet Altay wrote: > Kanban board for python 3: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=245 > > (Thank you

Re: [PROPOSAL] JIRA notification recipient changes

An INFRA ticket is needed. (As long as the report is automatically a watcher, the change is a strict improvement. If not, it's a strict degradation.) On Tue, Apr 17, 2018 at 1:55 PM, Kenneth Knowles wrote: > Hi all, > > Currently, every touch on a JIRA causes four

Re: [ANNOUCEMENT] New Foundation members!

Congrats! On Wed, Apr 18, 2018 at 2:45 PM, Tyler Akidau wrote: > 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: >>

Re: Add a (temporary) Portable Flink branch to the ASF repo?

+1 I would merge on master asap. Regards JB Le 18 avr. 2018 à 20:09, à 20:09, "Ismaël Mejía" a écrit: >+1 to bring this to ASF repo ASAP. Also +1 to Aljoscha's idea if we >can guarantee no interference. An extra branch has the issue of >rebasing that will be 'automatically'

Re: Gradle Status [April 11]

Great thanks for that! Makes perfect sense. On Wed, Apr 11, 2018 at 7:59 PM, Kenneth Knowles wrote: > There are plenty of technical hurdles since Bazel is best suited to an > isolated monorepo. We could probably have overcome those problems with > effort. I got through a few of

Re: [BEAM-4088] Test isolation differences in Gradle

Does the test think a thread leaked when no thread leaked? On Wed, Apr 18, 2018 at 1:51 PM Romain Manni-Bucau wrote: > The leaking threadq are already dumped but we dont track who created it > > Le 18 avr. 2018 22:50, "Kenneth Knowles" a écrit : > >> For