I added "Runtime / Configuration" to the proposal: https://cwiki.apache.org/confluence/display/FLINK/Proposal+for+new+JIRA+Components
Since this discussion has been open for 10 days, I assume we have reached consensus here. I will soon start renaming components. On Wed, Feb 13, 2019 at 10:51 AM Chesnay Schepler <ches...@apache.org> wrote: > The only parent I can think of is "Infrastructure", but I don't quite > like it :/ > > +1 for "Runtime / Configuration"; this is too general to be placed in > coordination imo. > > On 12.02.2019 18:25, Robert Metzger wrote: > > 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 > >>>>>> > >> > >
