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 code, it looks like these each exist to some level of completion. Kenn On Wed, Mar 7, 2018 at 1:38 PM Robert Bradshaw <rober...@google.com> wrote: > 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 are, or are brought up to snuff). > > > On Wed, Mar 7, 2018 at 1:35 PM Henning Rohde <hero...@google.com> wrote: > >> 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 believe it's only windowing, validation tests and documentation) >> reasonably quickly to get to an official vote for accepting it and in turn >> get master into a sound state. It would seem like the path of least hassle. >> Of course, I'm happy to go with whatever the community is comfortable with >> -- just trying to make lemonade out of the merge lemon. >> >> Henning >> >> [1] >> https://lists.apache.org/thread.html/fd4201980d7a6e67248b1f183ee06b0ff1305bd46f1291495679fc0a@%3Cdev.beam.apache.org%3E >> >> On Tue, Mar 6, 2018 at 3:40 PM, Kenneth Knowles <k...@google.com> wrote: >> >>> 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 <rober...@google.com> >>> wrote: >>> >>>> 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 <k...@google.com> wrote: >>>> >>>>> 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 <t...@apache.org> wrote: >>>>> >>>>>> +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 <rober...@google.com> >>>>>> 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 that have gone >>>>>>> in >>>>>>> since then. >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 6, 2018 at 2:43 PM Kenneth Knowles <k...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 to go-sdk merge it will need to be >>>>>>>> re-reverted. >>>>>>>> >>>>>>>> Two other options are (1) leave it there and disable it in whatever >>>>>>>> way and (2) rebase dropping the commit and force push master (breaks >>>>>>>> all >>>>>>>> checkouts that are past it). >>>>>>>> >>>>>>>> Kenn >>>>>>>> >>>>>>> >>>>>> >>
