Re: github reviews weirdness

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 Manni-Bucau @rmannibucau | Blog | Old Blog

Re: github reviews weirdness

I noticed that GitHub sometimes has two "copies" of a comment thread--the first copy, the one that appears first on the page with the original commenter, is the only one that allows comments; a second "copy" is created when people do reviews. So maybe you can scroll up to find the right "copy" of

github reviews weirdness

Hey guys, Noticed on some PR it is not possible to comment anymore the reviews comments. This is quite bothering cause it makes the review comments split and at the end quite hard to follow when you get > 1 iteration. Anything important I miss here? Should I use another tool - if so, why not

Re: Beam 2.4.0

By the way, if third party projects based on Beam (Google Dataflow, Talend DataStream, and others) need a release (including some features), it's better to clearly state this on the mailing list. At Apache Karaf, I have lot of projects based on it (OpenDaylight, OpenHAB, Websphere, ...). They

Re: Beam 2.4.0

A month is OK for me: I prefer that than longer (as it was before). The most important is a regular pace: we should avoid a 2.4.0 now and a 2.5.0 four months later. So, it means that 2.5.0 should happen roughly end of April. I will send a clear statement (as I already did weeks ago) around

Re: Beam 2.4.0

To be semver, 2.3.1 should be rollback safe with 2.3.0. Normally that is accomplished by cutting 2.3.1 release branch from 2.3.0 release branch and then have fixes cherrypicked. I think 6 weeks between minor version releases is not too fast. I think a month is a good target. We tend to have high

Re: Beam 2.4.0

That's the point of my e-mail indeed. I think it would make more sense for users. Regards JB On 02/28/2018 06:04 AM, Romain Manni-Bucau wrote: > Thinking out loud: why not trying a 2.3.1 with small fixes only and the 2.4 > after 6 weeks starting from the 2.3.0 real release date. > > Le 28

Re: Beam 2.4.0

Thinking out loud: why not trying a 2.3.1 with small fixes only and the 2.4 after 6 weeks starting from the 2.3.0 real release date. Le 28 févr. 2018 04:24, "Jean-Baptiste Onofré" a écrit : > OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a release is > out, >

Re: Beam 2.4.0

OK, maybe I wasn't clear: for me the cycle is ~ 6 weeks once a release is out, not when it started. I don't remember about monthly release (it's too fast IMHO). Anyway, let me find the thread dealing with release pace and propose a clear statement. It's important for our users. Regards JB On

Re: Beam 2.4.0

It's been six weeks since you proposed beam 2.3.0. so assuming the same time scale for this release, that's 1.5 months between releases. Slightly faster than 2 months, but not by much. I do seem to remember that the original goal for beam was monthly releases though. Reuven On Tue, Feb 27,

Re: Beam 2.4.0

Hi Reuven, In a previous thread (about Beam project execution), I proposed a release every two months (as a best effort), I will find the e-mail. Beam 2.3.0 has been released "officially" on February 16th, so two week ago roughly. I would have expected 2.4.0 not before end of March. If we have

Re: Beam 2.4.0

Wasn't the original statement monthly releases? We've never realistically managed that, but Robert's proposed cut will be on a 6-week pace. On Tue, Feb 27, 2018, 8:48 PM Jean-Baptiste Onofré wrote: > Hi Robert, > > I'm just curious: it's pretty fast compared to the original

Re: Beam 2.4.0

Hi Robert, I'm just curious: it's pretty fast compared to the original plan of a release every two months. What's the reason to cut 2.4.0 now instead of end of March ? I will do the Jira triage and update today. Regards JB On 02/27/2018 09:21 PM, Robert Bradshaw wrote: > I'm planning on

Python 3 flake 8: splitting up on the errors?

How would folks feel about splitting up some of the Python 3 migration work by the different flake8 errors in Py3? This might allow us to parallelize some of the work while still keeping things fairly small? -- Twitter: https://twitter.com/holdenkarau

Re: Beam 2.4.0

The issue isn't that we miss teardown, it's that WaitUntilFinish doesn't wait until all teardown calls have finished. However this is nearly as bad as not calling teardown at all, and can result in flaky tests. I think we should make an effort to get this fix into 2.4.0, but I also don't think we

Re: Beam 2.4.0

Not sure when it appeared but running any test you miss the teardown which is: 1. A part you cant test today cause of that 2. Leaking and can impact other tests depending the impl and setup 3. Prevent any correct concurrency plannification of tests (even using the random of the direct runner you

Re: Beam 2.4.0

Ok, I see. This bug is specifically about Teardown behavior. On Tue, Feb 27, 2018 at 1:33 PM Reuven Lax wrote: > Can you explain "unusable?" We have hundreds of direct-runner tests that > appear to still be running just fine. Is this a new regression, or old > behavior? > > >

Re: Beam 2.4.0

Can you explain "unusable?" We have hundreds of direct-runner tests that appear to still be running just fine. Is this a new regression, or old behavior? On Tue, Feb 27, 2018 at 1:30 PM Romain Manni-Bucau wrote: > Updated 3409 as blocker since it makes direct runner -

Re: Beam 2.4.0

Updated 3409 as blocker since it makes direct runner - and therefore any test - unusable at all (leaks+unexpected wait times + retry strategy required+no real alternative even for dofn now dofntester is deprecated). Le 27 févr. 2018 21:45, "Chamikara Jayalath" a écrit : >

Re: Beam 2.4.0

Looks like previous URL was broken. Created https://s.apache.org/beam-2.4.0-burndown. - Cham On Tue, Feb 27, 2018 at 12:22 PM Robert Bradshaw wrote: > I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see 13 > open issues on JIRA [1], none of which are

Beam 2.4.0

I'm planning on cutting the 2.4.0 release branch soon (tomorrow?). I see 13 open issues on JIRA [1], none of which are labeled as blockers. If there are any that cannot be bumped to the next release, let me know soon. - Robert [1]

Re: Euphoria Java 8 DSL - proposal

(Sounds good, thanks! We'll follow-up there.) On Tue, Feb 27, 2018 at 10:49 AM, David Morávek wrote: > Hi Davor, > > sorry for the delay, we were blocked by our legal department. I've send > both SGA and CCLA to priv...@apache.beam.org, please let me know if you > need

Re: Euphoria Java 8 DSL - proposal

Hi Davor, sorry for the delay, we were blocked by our legal department. I've send both SGA and CCLA to priv...@apache.beam.org, please let me know if you need anything else. Regards, David On Mon, Feb 19, 2018 at 6:13 AM, Jean-Baptiste Onofré wrote: > Hi Davor, > > We still

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

Thanks for fixing the manual cleanup issue! This is something we kept punting on in previous releases. On Mon, Feb 26, 2018 at 7:14 PM Jean-Baptiste Onofré wrote: > Hi Alan, > > Honestly, it was an easy and smooth release, similar to other Apache > project > release. > >

Jenkins build is back to normal : beam_SeedJob #1178

See

Build failed in Jenkins: beam_SeedJob #1177

See -- GitHub pull request #4758 of commit 4b0a07f826103899d5b7884490059b5498f064f3, no merge conflicts. Setting status of 4b0a07f826103899d5b7884490059b5498f064f3 to PENDING with url

Build failed in Jenkins: beam_SeedJob #1176

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

Build failed in Jenkins: beam_SeedJob #1175

See -- GitHub pull request #4758 of commit e5b6fd79420a4cfccf5c5dce40e0a0233c8bd7f2, no merge conflicts. PR merge status couldn't be retrieved, maybe GitHub hasn't settled yet Setting

Jenkins build is back to normal : beam_SeedJob #1174

See

Build failed in Jenkins: beam_SeedJob #1173

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