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 overlooked. If this presence of the Go SDK in master cause
issues for other modules, please simply file a bug against me and I'll take
care of it.

Robert - I understand your last reply as addressing Davor's points. Please
let me know if there is anything I need to do in that regard.

Henning



On Fri, Mar 9, 2018 at 8:39 AM, Ismaël Mejía <ieme...@gmail.com> wrote:

> +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 <rober...@google.com>
> wrote:
> > +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 <da...@apache.org> wrote:
> >>
> >> 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
> >> on the new component and accepted. This includes source releases that
> are
> >> created through "assembly", so manual exclusion in the configuration is
> >> likely needed.
> >>
> >> On Wed, Mar 7, 2018 at 1:54 PM, Kenneth Knowles <k...@google.com> wrote:
> >>>
> >>> 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/fd4201980d7a6e67248b1f183ee06b
> 0ff1305bd46f1291495679fc0a@%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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>
> >>
> >
>

Reply via email to