Nice! I'm happy to see that the components are evolving (this means they are used :) ) This is also a good test for my latest changes to the GitHub labeling tools. They should support label changes.
On Fri, Mar 22, 2019 at 10:18 AM Aljoscha Krettek <aljos...@apache.org> wrote: > Perfect! I re-arranged the components and created some new ones to fit > this. Right now, most issues are still in “Table SQL / API” I’ll start to > move issues to other components but please try and have a look as well and > move issues to the correct components. > > See here for how many issues are in each component: > https://issues.apache.org/jira/projects/FLINK?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > < > https://issues.apache.org/jira/projects/FLINK?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > > > > Aljoscha > > > On 22. Mar 2019, at 03:20, Jark Wu <imj...@gmail.com> wrote: > > > > +1 to Timo's proposal. > > > > Best, > > Jark > > > > On Fri, 22 Mar 2019 at 07:42, Kurt Young <ykt...@gmail.com> wrote: > > > >> +1 to Timo's proposal. > >> > >> Timo Walther <twal...@apache.org>于2019年3月21日 周四21:40写道: > >> > >>> Hi everyone, > >>> > >>> I also tried to summarize the previous discussion and would add an > >>> additional `Ecosystem` component. I would suggest: > >>> > >>> Table SQL / API > >>> Table SQL / Client > >>> Table SQL / Legacy Planner > >>> Table SQL / Planner > >>> Table SQL / Runtime > >>> Table SQL / Ecosystem (such as table connectors, formats, Hive catalog > >>> etc.) > >>> > >>> This should make everyone happy, no? > >>> > >>> Thanks for proosing this Aljoscha. Big +1. > >>> > >>> Regards, > >>> Timo > >>> > >>> Am 21.03.19 um 14:31 schrieb Aljoscha Krettek: > >>>> Cool, I like this. I have one last suggestion. How about this: > >>>> > >>>> Table SQL / API > >>>> Table SQL / Client > >>>> Table SQL / Classic Planner (or Legacy Planner): Flink Table SQL > >> runtime > >>> and plan translation. > >>>> Table SQL / Planner: plan-related for new Blink-based Table SQL > runner. > >>>> Table SQL / Runtime: runtime-related for new Blink-based Table SQL > >>> runner. > >>>> > >>>> It’s Jark’s version but I renamed "Table SQL / Operators" to “Table > SQL > >>> / Runtime", because it is not only operators but all the supporting > code > >>> around that which is needed at, well, runtime. ;-) > >>>> > >>>> What do you think? > >>>> > >>>> Best, > >>>> Aljoscha > >>>> > >>>> > >>>>> On 21. Mar 2019, at 03:52, Jark Wu <imj...@gmail.com> wrote: > >>>>> > >>>>> +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 <mailto: > >>> 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 > >>> <mailto: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 > >>>> > >>> > >>> -- > >> Best, > >> Kurt > >> > >