Some concerns:
Travis and build system / release system are entirely different. I would
even keep the release system away from the build-system, as it is more
about the release scripts and documentation, while the latter is about
maven. Actually I'd just rename build-system to maven.
Control Plane is a term I've never heard before in this context; I'd
replace it with Coordination.
The "Documentation" descriptions refers to it as a "Fallback component".
In other words, if I make a change to the metrics documentation I
shouldn't use this component any more?
I don't see the benefit of a `Misc` major category. I'd attribute
everything that doesn't have a major category implicitly to "Misc".
Not a fan of a generalized "Legacy components" category; this seems
unnecessary. It's also a bit weird going forward as we'd have to touch
every JIRA for a component if we drop it.
How come gelly/CEP don't have a Major category (libraries?)
"End to end infrastructure" is not equivalent to "E2E tests".
Infrastructure is not about fixing failing tests, which is what we
partially used this component for so far.
I don't believe you can get rid of the generic "Tests" component;
consider any changes to the `flink-test-utils-junit` module.
You propose deleting "Core" and "Configuration" but haven't listed any
migration paths.
If there's a API / Python category there should also be a API / Scala
category. This could also include the shala-shell. Note that the
existing Scala API category is not mentioned anywhere in the document.
How do you actually want to do the migration?
On 08.02.2019 13:13, Timo Walther wrote:
Hi Robert,
thanks for starting this discussion. I was also about to suggest
splitting the `Table API & SQL` component because it contains already
more than 1000 issues.
My comments:
- Rename "SQL/Shell" to "SQL/Client" because the long-term goal might
not only be a CLI interface. I would keep the generic name "SQL
Client" for now. This is also what is written in FLIPs, presentations,
and documentation.
- Rename "SQL/Query Planner" to "SQL/Planner" a query is read-only
operation but we support things like INSERT INTO etc.. Planner is more
generic.
- Rename "Gelly" to "Graph Processing". New users don't know what
Gelly means. This is the only component that has a "feature name". I
don't know if we want to stick with that in the future.
- Not sure about this: Introduce a "SQL/Connectors"? Because SQL
connectors are tightly bound to SQL internals but also to the
connector itself.
- Rename "Connectors/HCatalog" to "Connectors/Hive". This name is more
generic and reflects the efforts about Hive Metastore and catalog
integration that is currenlty taking place.
Thanks,
Timo
Am 08.02.19 um 12:39 schrieb Robert Metzger:
Hi all,
I am currently trying to improve how the Flink community is handling
incoming pull requests and JIRA tickets.
I've looked at how other big communities are handling such a high
number of
contributions, and I found that many are using GitHub labels
extensively.
An integral part of the label use is to tag PRs with the component /
area
they belong to. I think the most obvious and logical way of tagging
the PRs
is by using the JIRA components. This will force us to keep the JIRA
tickets well-organized, if we want the PRs to be organized :)
I will soon start a separate discussion for the GitHub labels.
Let's first discuss the JIRA components.
I've created the following Wiki page with my proposal of the new
component,
and how to migrate from the existing components:
https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Please comment here or directly in the Wiki to let me know what you
think.
Best,
Robert
