+1 Sounds great!
> On 9. Sep 2017, at 00:44, Kenneth Knowles <k...@google.com.INVALID> wrote: > > +1 to this. > > It is really easy to lose track of things in a sea of tickets, and > portability touches every SDK and runner, so getting this organized will be > hugely helpful. Especially getting some clear higher-level milestones (by > moving tickets to subtasks) we can work towards and announce when done will > be great. > > Kenn > > On Fri, Sep 8, 2017 at 1:59 PM, Henning Rohde <hero...@google.com.invalid> > wrote: > >> Hi everyone, >> >> The portability effort involves a large amount of work cutting across all >> SDKs and runners [e..g, 1,2,3,4]. It seems to be only partially captured in >> JIRAs, so I'd like to volunteer to try to flesh it out further. In addition >> to adding JIRAs for missing work, I was thinking of organizing it as >> follows: >> >> (1) Designs, proto definitions and the like belong in the "beam-model" >> component. For example, BEAM-2862 tracks support for User State over the Fn >> API. >> (2) Dependent work are subtasks belong in the component where the work is >> needed. For example, making the Python SDK harness use the User State over >> the Fn API would be in the "sdk-py" component and be a subtask (or >> otherwise linked to) the overall BEAM-2862 issue. Similarly for each runner >> and other SDKs. >> (3) All portability issues should use a "portability" label, regardless >> of component, to identify the overall effort. >> >> The aim is to make it more clear to see what works (and remains to be done) >> from both the point of view of each SDK and runner as well as feature-wise >> for portability. >> >> Please let me know if you have any comments or objections. >> >> Thanks, >> Henning >> >> [1] https://s.apache.org/beam-fn-api >> [2] https://s.apache.org/beam-runner-api >> [3] https://s.apache.org/beam-job-api >> [4] https://s.apache.org/beam-fn-api-container-contract >>
