Hi Aljoscha, +1 to further separate table-relate jira components, but I would prefer to move "Runtime / Operators" to a dedicated "Table SQL / Operators". There is one concern about the "classic planner" and "new planner", the naming will be inaccurate after blink merge done and we deprecated classic planner later (if it happens). If only one planner left, then what component should we use when creating jira?
How about this: Table SQL / API Table SQL / Client Table SQL / Planner Table SQL / Operators Best, Kurt On Thu, Mar 21, 2019 at 12:39 AM Aljoscha Krettek <aljos...@apache.org> wrote: > Hi, > > First of all, I hope I cc’ed all the relevant people. Sorry if I forgot > anyone. > > I would like to restructure the Table/SQL-related Jira components a bit > more to better reflect the current state of components. Right now we have: > > * API / Table SQL: this is just a wild collection of table-related things > * Runtime / Operators: this has general operators stuff, but also new > Blink-based Table operator stuff and maybe classic Table runner stuff > * SQL / Client: as it says > * SQL / Planner: this has issues for the existing classic Flink Table > runner and new things related to merging of the new Blink-based Table Runner > > I would suggest to reorganise it like this: > > * API / Table SQL: API-related things > * API / Table SQL / Client: the SQL client > * API / Table SQL / Classic Planner: things related to classic Flink Table > API runtime and plan translation, everything to do with execution > * API / Table SQL / New Planner: runtime operators, translation, > everything really, for the new Blink-based Table API/SQL runner > > Runtime / Operators would be used purely for non-table-related > operator/runtime stuff. > > What do you think? “Classic Planner” and “New Planner” are up for > discussion. 😅 We could even get rid of the API prefix, it doesn’t really > do much, I think. > > Best, > Aljoscha
