[wildfly-dev] Re: Applying to Commonhaus

On Thu, Mar 13, 2025 at 11:34 AM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: > On Thu, Mar 13, 2025 at 7:31 AM Carlo de Wolf <cdewolf(a)redhat.com&gt; wrote: > >> On 12-03-2025 22:45, Brian Stansberry wrote: >> >> It will also cover a few repos in the 'jboss' and 'jbossas' Github orgs >> that really should be moved to the 'wildfly' org. >> >> >> Can we get a list of repos in jbossas to be moved? >> > > Before answering, I'll give a bit of context for the benefit of others. > There are quite a lot of repos in the 'jbossas' org that relate to Red Hat > JBoss EAP. So my basic thinking is to leave that org to EAP, and move the > few remaining unarchived repos that host WildFly components to the > 'wildfly' org. > > This is subject to agreement with the relevant maintainers, but these > are the projects hosting upstream components that I think make sense to > move to 'wildfly' Github org and include in any move to Commonhaus: > > jboss-classfilewriter > jboss-dmr > jboss-iiop-client > jboss-invocation > jboss-vfs > remoting-jmx > staxmapper > > I didn't list the JBoss Threads repo, as that's a commonly used > component, not something with the bulk of its use and requirement > definitions coming from WildFly. That project is actually quite far ahead > of what WildFly uses. (Work is underway to catch up though!) > Realistically JBoss Threads (and a few other projects) are primarily consumed by just WildFly and Quarkus (which is also making the move to Commonhaus). It would be unfortunate if these projects were left behind due to not fitting cleanly into one or the other camp, despite both camps being moved to the foundation. I am not quite sure what to do about it though. Moving the projects individually seems silly, but other than that I don't know of any other options.

-- - DML • he/him