Hi all,
You may have noticed that our tests are red. A pull request that was meant
for the Go SDK branch accidentally got merged onto the master branch.
Things have been merged to master since then.
I've opened a revert at https://github.com/apache/beam/pull/4808
The next time there is a master
I'm reading "The next time..." as the Go developers needs to take some
special precautions the next time they merge from master to go-sdk? If
that's correct, that's more than reasonable, especially in light of this
current breakage.
Please do whatever's necessary to make things right again. If the
I would opt for (2), but I'm not sure who has permissions to do that. It
should be easy to re-merge the couple of things that have gone in since
then.
On Tue, Mar 6, 2018 at 2:43 PM Kenneth Knowles wrote:
> Hi all,
>
> You may have noticed that our tests are red. A pull request that was meant
>
+1 for (1), assuming it is straightforward to exclude from the build and
eventually will end up in master anyways.
On Tue, Mar 6, 2018 at 2:59 PM, Robert Bradshaw wrote:
> I would opt for (2), but I'm not sure who has permissions to do that. It
> should be easy to re-merge the couple of things t
My own vote is for leaving the history immutable, which is the case for the
full rollback or leaving it there disabled.
On Tue, Mar 6, 2018 at 3:01 PM Thomas Weise wrote:
> +1 for (1), assuming it is straightforward to exclude from the build and
> eventually will end up in master anyways.
>
> O
Can we open up the pair of commits so that master gets reverted and the Go
SDK merges from master plus another rollback?
On Tue, Mar 6, 2018 at 2:42 PM, Kenneth Knowles wrote:
> Hi all,
>
> You may have noticed that our tests are red. A pull request that was meant
> for the Go SDK branch acciden
I'm happy to deal with any needed fixup on the Go SDK side in either case.
On Tue, Mar 6, 2018 at 3:20 PM, Lukasz Cwik wrote:
> Can we open up the pair of commits so that master gets reverted and the Go
> SDK merges from master plus another rollback?
>
> On Tue, Mar 6, 2018 at 2:42 PM, Kenneth K
Looks like the only issue is a snapshot version in the pom.
On Tue, Mar 6, 2018 at 3:28 PM Henning Rohde wrote:
> I'm happy to deal with any needed fixup on the Go SDK side in either case.
>
> On Tue, Mar 6, 2018 at 3:20 PM, Lukasz Cwik wrote:
>
>> Can we open up the pair of commits so that ma
I'm not sure what value there is in preserving this accidental merge in
history, but all options proposed seem fine to me. We should resolve this
(or at least unblock other dev work) quickly though.
On Tue, Mar 6, 2018 at 3:16 PM Kenneth Knowles wrote:
> My own vote is for leaving the history i
I think a very easy fix to unblock everyone is
https://github.com/apache/beam/pull/4809. It just updates one line of a pom.
On Tue, Mar 6, 2018 at 3:33 PM Robert Bradshaw wrote:
> I'm not sure what value there is in preserving this accidental merge in
> history, but all options proposed seem fi
One thought: the Go SDK is actually not that far away from satisfying the
guidelines for merging to master anyway (as discussed here [1]). If we
decide to simply leave the code in master -- which seems to be what this
thread is leaning towards -- I'll gladly sign up to do the remaining
aspects (I b
I was actually thinking along the same lines: what was yet lacking to
"officially" merge the Go branch in? The thread we started on this seems to
have fizzled out over the holidays, but windowing support is the only
must-have missing technical feature in my book (assuming documentation and
testing
Re-reading the old thread, I see these desirata:
- "enough IO to write end-to-end examples such as WordCount and
demonstrate what IOs would look like"
- "accounting and tracking the fact that each element has an associated
window and timestamp"
- "test suites and test utilities"
Browsing the c
I support leaving things as they stand now -- thanks for finding a good way
out of an uncomfortable situation.
That said, two things need to happen:
(1) SGA needs to be filed asap, per Board feedback in the last report, and
(2) releases cannot contain any code from the Go SDK before formally voted
+1 to both of these points. SGA should have probably already been filed,
and excising this from releases should be easy, but I added a line item to
the validation checklist template to make sure we don't forget.
On Thu, Mar 8, 2018 at 7:13 AM Davor Bonaci wrote:
> I support leaving things as the
+1 to let it evolve in master (+Davor points), having ongoing work on
master makes sense given the state of advance + the hope that this
won't add any issue for the other modules.
On Thu, Mar 8, 2018 at 7:30 PM, Robert Bradshaw wrote:
> +1 to both of these points. SGA should have probably already
Thank you all! I've added the remaining work -- as I understand it -- as
dependencies to the overall Go SDK issue (tracking the "official" merge to
master):
https://issues.apache.org/jira/browse/BEAM-2083
Please feel free to add to this list or expand the items, if there is
anything I overloo
Hi everyone,
Thank you all for your patience. The last major identified feature (Go
windowing) is now in review: https://github.com/apache/beam/pull/5179. The
remaining work listed under
https://issues.apache.org/jira/browse/BEAM-2083
is integration tests and documentation (quickstart, etc
Hi everyone,
Thanks again for your patience. The last remaining Go SDK items are now
resolved and the beam website has been updated! I'll start a separate
thread for the formal vote shortly.
Thanks,
Henning
On Thu, Apr 19, 2018 at 5:42 PM Henning Rohde wrote:
> Hi everyone,
>
> Thank you a
19 matches
Mail list logo
