Thanks a lot for your feedback Chesnay! re build/travis/release: Do you have a good idea for a common parent for "Build System", "Travis" and "Release System"?
re legacy: Okay, I see your point. I will keep the Legacy Components prefix. re library: I think I don't have a argument here. My proposal is based on what I felt as being right :) I added the "Library / " prefix to the proposal. re core/config: From the proposed components, I see the best match with "Runtime / Coordination", but I agree that this example is difficult to place into my proposed scheme. Do you think we should introduce "Runtime / Configuration" as a component? I updated the proposal accordingly! On Tue, Feb 12, 2019 at 12:19 PM Chesnay Schepler <ches...@apache.org> wrote: > re build/travis/release: No, I'm against merging build system, travis > and release system. > > re legacy: So going forward you're proposing to move dropped features > into the legacy bucket and make it impossible to search for specific > issues for that component? There's 0 overhead to having these > components, so I really don't get the benefit here, but see the overhead. > I don't buy the argument of "people will not open issues if the > component doesn't exist", they will just leave the component field blank > or add a random one (that would be wrong). In fact, if you had a > storm/tez component (that users would adhere to) then it would be > _easier_ to figure out whether an issue can be rejected right away. > > re library: If you are against a library category, what's your argument > for a connector category? > > re tests: I don't mind "tests" being removed from tickets about test > instabilities, but you specified the migration as "rename E2E tests" > which is not equivalent. > Under what category would you file modifications to flink-test-utils-junit? > I would propose to not differentiate between e2e and other tests; I > would go along with "Test infrastructure", and remove the major "Tests" > category. > > re core/config: As an example, where (under Runtime) would you place the > introduction of the ConfigOption class? > > On 11.02.2019 11:31, Robert Metzger 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 > >>>> > >>> > >> > >
