+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/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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>
>

Reply via email to