[DISCUSS] Reorganizing Table-related Jira components some more

[Aljoscha Krettek-2]

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

[Shaoxuan Wang]

+1 to restructure the Jira components.

How about:
Table / API
Table / Client
Table / Classic Planner (or Legacy Planner)
Table / New Planner

Regards,
Shaoxuan


On Thu, Mar 21, 2019 at 12:39 AM Aljoscha Krettek <[hidden email]>
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

[Kurt Young]

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 <[hidden email]>
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

[Jark Wu-2]

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

[Aljoscha Krettek-2]

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
> 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

[Timo Walther-2]

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>> 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
>

[Kurt Young]

+1 to Timo's proposal.

Timo Walther <[hidden email]>于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 <[hidden email]> 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 <[hidden email] <mailto:
> [hidden email]>> 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 <[hidden email]
> <mailto:[hidden email]>>
> >> 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

[Jark Wu-2]

+1 to Timo's proposal.

Best,
Jark

On Fri, 22 Mar 2019 at 07:42, Kurt Young <[hidden email]> wrote:

> +1 to Timo's proposal.
>
> Timo Walther <[hidden email]>于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 <[hidden email]> 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 <[hidden email] <mailto:
> > [hidden email]>> 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 <
> [hidden email]
> > <mailto:[hidden email]>>
> > >> 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
>

[Aljoscha Krettek-2]

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 <[hidden email]> wrote:
>
> +1 to Timo's proposal.
>
> Best,
> Jark
>
> On Fri, 22 Mar 2019 at 07:42, Kurt Young <[hidden email]> wrote:
>
>> +1 to Timo's proposal.
>>
>> Timo Walther <[hidden email]>于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 <[hidden email]> 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 <[hidden email] <mailto:
>>> [hidden email]>> 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 <
>> [hidden email]
>>> <mailto:[hidden email]>>
>>>>> 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
>>

[Robert Metzger]

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 <[hidden email]>
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 <[hidden email]> wrote:
> >
> > +1 to Timo's proposal.
> >
> > Best,
> > Jark
> >
> > On Fri, 22 Mar 2019 at 07:42, Kurt Young <[hidden email]> wrote:
> >
> >> +1 to Timo's proposal.
> >>
> >> Timo Walther <[hidden email]>于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 <[hidden email]> 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 <[hidden email] <mailto:
> >>> [hidden email]>> 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 <
> >> [hidden email]
> >>> <mailto:[hidden email]>>
> >>>>> 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
> >>
>
>