Re: [DISCUSS] Remove TimerInternals.deleteTimer(*) and Timer.cancel()

2017-05-08 Thread JingsongLee
+1 to remove this, I have not encountered such a strong case. best, JingsongLee -- From:Kenneth Knowles Time:2017 May 9 (Tue) 05:45 To:dev Subject:Re: [DISCUSS] Remove

Re: [DISCUSS] Remove TimerInternals.deleteTimer(*) and Timer.cancel()

2017-05-08 Thread Kenneth Knowles
Interesting! I believe the only thing we need to change to remove it for FSR is https://github.com/apache/beam/blob/master/sdks/java/core /src/main/java/org/apache/beam/sdk/state/Timer.java#L60 Here is how I might summarize the possibilities, at the risk of having something quite wrong: -

Re: Congratulations Davor!

2017-05-08 Thread Davor Bonaci
Thanks everyone! On Mon, May 8, 2017 at 12:05 PM, Stas Levin wrote: > Congrats! > > On Mon, May 8, 2017, 20:07 Tyler Akidau > wrote: > > > Very nice. Congrats! > > > > On Sun, May 7, 2017 at 4:38 AM Prabeesh K. wrote: > >

First stable release: release candidate #1

2017-05-08 Thread Davor Bonaci
The release candidate #1 for the version 2.0.0 has been built. The complete staging area is available for review, which includes: * JIRA release notes [1], * the official Apache source release to be deployed to dist.apache.org [2], which is signed with the key with fingerprint 8F0D334F [3], * all

First stable release: Acceptance criteria

2017-05-08 Thread Davor Bonaci
Based on the process previously discussed [1], I've seeded the acceptance criteria document [2]. Please consider contributing to this effort by: * proposing additional acceptance criteria, and/or * supporting criteria proposed by others, and/or * validating a criteria. Please note that

Re: Process for getting the first stable release out

2017-05-08 Thread Robert Bradshaw
On Mon, May 8, 2017 at 1:12 PM, Dan Halperin wrote: > I like putting in master then CPing into release, because we should have a > high bar for what goes into release. It should absolutely NOT default to > everything; we should have to justify everything. Agreed the

Re: Process for getting the first stable release out

2017-05-08 Thread Dan Halperin
I like putting in master then CPing into release, because we should have a high bar for what goes into release. It should absolutely NOT default to everything; we should have to justify everything. E.g., https://github.com/apache/beam/pull/2958 - where I open the CP but suggest this may not be

Re: Process for getting the first stable release out

2017-05-08 Thread Robert Bradshaw
On Mon, May 8, 2017 at 12:57 PM, Davor Bonaci wrote: > We cannot do (clean) merges; both branches contain unwanted changes in the > other branch. So, we have to cherry-pick regardless where we merge first. Shouldn't the set of changes wanted in release but not in master be

Re: Process for getting the first stable release out

2017-05-08 Thread Davor Bonaci
We cannot do (clean) merges; both branches contain unwanted changes in the other branch. So, we have to cherry-pick regardless where we merge first. With post commits running automatically on master only, that seems like a logical starting point. But, it doesn't matter really -- either way works.

Re: On emitting from finshBundle

2017-05-08 Thread Robert Bradshaw
I think we agree that emitting from FinalizeBundle without specifying the Window explicitly should be an error for anything but the global window (similar to global combine with defaults). The question is whether it should be allowable in the global window case for convenience (again, similar to

Re: First stable release: version designation?

2017-05-08 Thread Robert Bradshaw
I also have a definite (I guess that's closer to strong that slight) preference for 2.0. With version numbers, a gap is less likely to cause trouble than the ambiguity of an overlap, and easy to document (vs. with ambiguity, one wouldn't even think to consult the documentation without knowing the

Re: First stable release: version designation?

2017-05-08 Thread Pei HE
I vote for 2.0. On Sun, May 7, 2017 at 7:50 PM, Prabeesh K. wrote: > I also vote for 2.0. > > On 5 May 2017 at 21:33, Hadar Hod wrote: > > > I also vote for 2.0, for the same reasons Dan stated. > > As Cham mentioned, we can clarify any

[DISCUSS] Remove TimerInternals.deleteTimer(*) and Timer.cancel()

2017-05-08 Thread Aljoscha Krettek
I wanted to bring this up before the First Stable release and see what other people think. The methods I’m talking about are: void deleteTimer(StateNamespace namespace, String timerId, TimeDomain timeDomain); @Deprecated void deleteTimer(StateNamespace namespace, String timerId); @Deprecated