> If you maintain a project that is not in one of the categories above but
> that you believe fits into WildFly project governance, or could fit into a
> sensibly modified WildFly governance, and you'd like it to be considered
> part of this application, please let me know. If you want to discuss it
> here, that's fine.
I think the management console could fit into that category.
Makes sense.
Currently it lives in its own GitHub organization [1] which is also used to host other related projects like various test suites, HAL's website, UI-related frameworks and the work on the next-hen management console.
So while HAL itself is not used outside WildFly and could move to the wildfly org, I'm not sure how to deal with all the other projects currently in the HAL org.
I don't know if there's any requirement that a repo associated with a project moving to Commonhaus can't be in a Github org with repos that are not. I'm sure we'll find out as we go through the process. I expect the overall project leadership needs to control the repo, but I don't know that being part of a GH org not completely associated with Commonhaus is a problem.
Note that some of my discussion here of moving repos to the 'wildfly' GH org was something I thought we should do anyway, just as a form of housekeeping, where we have orgs that for historical reasons have bits and pieces of things used in different ways. The HAL org is a coherent one that AFAIK doesn't need tidying.
[1] https://github.com/hal
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/5ECW2X6WW5YKMKSKQTMSP5NPQHHWPKCP/