Thanks a lot for your feedback! @Timo: I've followed your suggestions and updated the proposed names in the wiki.
Regarding a new "SQL/Connectors" component: I (with admittedly not much knowledge) would not add this component at the moment, and put the SQL stuff into the respective connector component. It is probably pretty difficult for a user to decide whether a but belongs to "SQL/Connector" to "Connectors/Kafka" when Kafka in SQL does not work. @Chesnay: - You are suggesting to rename "Build System" to "Maven" and still merge it with "Travis", "Release System" etc. as in the proposal? - "Runtime / Control Plan" vs "Runtime / Coordination" -- I changed the proposal - Re. "Documentation": Yes, I think that would be better in the long run. We are already in a situation where there are groups within the community focusing on certain areas of the code (such as SQL, the runtime, connectors). Those groups will monitor their components, but it will be a lot of overhead for them to monitor the "Documentation" component. We can also try to assign documentation components to both "Documentation" and the affected component, such as "Runtime / Metrics". - Removed "Misc / " prefix. - "Legacy Components": Usually legacy components usually have very few tickets. "Flink on Tez" has 13, "Storm Compat" ~30, and JIRA has a bulk edit feature :) The benefit of having it generalized is that people will probably not add tickets to it. - "Libraries /" prefix: I don't think that it is necessary. Some libraries might grow in the future (like the Table API), then we need to rename. the "flink-libraries" module does contain stuff like the sql client or the python api, which are already covered by other components in my proposal -- so going with the maven module structure is not an argument here. - "End to end infrastructure" and "Tests: The same argument as with the "Documentation" applies here. The maintainers of Kafka, Metrics, .. should get visibility into "their" test instabilities through "their" components. Not many people will feel responsible for the "Tests" component. For "Core" and "Configuration", I will move the tickets to the appropriate components in "Runtime /". For "API / Scala": Good point. I will add that component. How to do it? I will just go through the pain and do it. Best, Robert On Fri, Feb 8, 2019 at 2:40 PM Chesnay Schepler <ches...@apache.org> wrote: > 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 > >> > > > > > >
