+1 to Kurt's proposal which removes the "API" prefix and add a table's operator component.
In the other hand, I think it's worth to distinguish Blink SQL issues and Flink SQL issues via the component name. Currently, it's hard to distinguish. How about: Table SQL / API Table SQL / Client Table SQL / Legacy Planner: Flink Table SQL runtime and plan translation. Table SQL / New Planner: plan-related for new Blink-based Table SQL runner. Table SQL / Operators: runtime-related for new Blink-based Table SQL runner. Once blink merge is done, we can combine "Table SQL / Legacy Planner" and "Table SQL / New Planner" into Table SQL / Planner". Best, Jark On Thu, 21 Mar 2019 at 10:21, Kurt Young <ykt...@gmail.com> wrote: > 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 >
