[ https://issues.redhat.com/browse/WFLY-1415?page=com.atlassian.jira.plugin... ] Brian Stansberry edited comment on WFLY-1415 at 4/8/20 1:29 PM: ---------------------------------------------------------------- [~lvydra]. I think this is still valid. I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask. I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs: 1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads. I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFCORE?selectedItem=com.atlassian.jira...), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA. 2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general. Full WildFly component leads are at (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.j...) 3) The kernel parsers in WF Core. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces. Any work would be tracked via a WFCORE. 4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc. This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done. was (Author: brian.stansberry): [~lvydra]. I think this is still valid. I think it is too broadly scoped though, so any work should be done via more narrow subtasks with a separate JIRA per subtask. I see a number of general *categories* of subtasks, with each category often involving distinct subtask JIRAs: 1) Subsystems in WildFly Core that do not use PersistentResourceXMLParser/PersistentResourceXMLDescription for their parsing. At a glance I think that's deployment-scanner, jmx, logging, remoting, maybe threads. I think a place to start is with one or more of these (not threads at first). You could contact the lead for the component (https://issues.redhat.com/projects/WFLY?selectedItem=com.atlassian.jira.j...), check with them and then file a subtask WFCORE for that subsystem. One PR per JIRA. 2) Same for subsystems in full WildFly. (I haven't looked which there are.) Those would be tracked with WFLY JIRAs. Lower priority; better to start with WF Core to get familiar while interacting with the WF Core devs, who are more familiar with management code in general. 3) The kernel parsers. (StandaloneXml, HostXml, DomainXml and related classes.). This is a big job and requires careful planning as we wouldn't want to disrupt more critical work. Perhaps it could be divided into smaller less disruptive pieces. 4) There may be some other misc parsers to eventually look at. Deployment descriptors, CLI config etc. This seems like something where the best thing is to find subsystems where there isn't much activity (so any change isn't disruptive to other work), and then when you (or others) have some spare time contact the subsystem lead, file a JIRA and get that one done. -- This message was sent by Atlassian Jira (v7.13.8#713008)