I would say that *most* of it is not suitable for direct merging. There are
several reasons for this:
- Most changes are built on upstream PRs that are either not submitted
or have been rebased before submission.
- There are some very hacky changes in the Python and Java SDKs to get
portable pipelines working. For example, hard coding certain options and/or
baking dependencies into the SDK harness images. These need to be actually
implemented correctly in their respective SDKs.
- Much of the code does not have proper tests and fails simple lint
As a concrete example, I tried cherry-picking the changes from
https://github.com/bsidhom/beam/pull/46 into master. This is a relatively
simple change, but there were so many merge conflicts that in the end it
was easier to just reimplement the changes atop master. More importantly,
most changes will require refactoring before actually going in.
On Thu, Apr 12, 2018 at 3:16 PM, Robert Bradshaw <rober...@google.com>
> How much of this is not suitable to merging into master directly (not as
> is, but as separate PRs)?
> On Thu, Apr 12, 2018 at 3:10 PM Ben Sidhom <sid...@google.com> wrote:
> > Hey all,
> > I've been working on a proof-of-concept portable Flink runner with some
> other Beam contributors. We would like to have a point of reference for the
> rest of the Beam community as we integrate this work into master. It
> currently lives under
> > I would suggest pulling this into the main ASF repo under an
> appropriately-named branch (flink-portable-hacking?). The name should
> suggest the intention that this branch is not intended to be pulled into
> master as-is and that it should rather be used as a reference for now.
> > Thoughts?
> > --
> > -Ben