+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 <[email protected]> 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 >
