> > We can also try to assign documentation components to both "Documentation" > and the affected component, such as "Runtime / Metrics".
This is critical for anyone trying to keep an eye on the documentation as a whole -- e.g., ensuring that it remains readable, is well-organized, and is being translated. On Mon, Feb 11, 2019 at 11:32 AM Robert Metzger <rmetz...@apache.org> wrote: > 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 > > >> > > > > > > > > > > >
