Use of the 'org.wildfly' groupId
by Brian Stansberry
Currently we have a number of different repos publishing artifacts using
the 'org.wildfly' groupId with no further namespacing.
Going forward I don't think we should allow any other new repos to do that.
It leads to administrative hassles, e.g. with setting things up in Nexus.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
3 weeks
Help Wanted! -- Assets to transfer to Commonhaus
by Brian Stansberry
WildFly joining Commonhaus was formally announced today. :-) (See [1]). As
I noted in the announcement, we're now beginning the process of onboarding
to Commonhaus. Part of that is identifying the various 'assets' that will
be transferred from Red Hat to Commonhaus.
HELP WANTED on this! We have an opportunity to proceed more quickly on this
asset transfer piece than I thought, but only if we act promptly to provide
information.
I have created a google document at [2] to record details of various types
of assets we will transfer. I can really use your help with adding anything
that is missing. Anyone can comment on the doc, so simplest is to directly
edit the file to add things; your edits will be recorded as suggestions.
I'm looking for things in 5 categories -- 'Source Code Repositories',
'Domain Names', 'Hosting Accounts', 'Social Media and Email Accounts' and
'Trademarks'. The google doc has definitions of these, and from the ones
I've already entered you can get a sense of the basic idea.
When in doubt, suggest it! And leave a comment about the doubt.
Note that the discussion of the scope of 'WildFly' on the 'Applying to
Commonhaus' thread is relevant, so part of doing this will be firming up
things discussed there. (If something discussed there is not covered in my
initial draft of the doc; don't read anything into that, just help me by
pointing that out.)
NOTE: This DOES NOT need to be perfect. We can correct errors, add missing
things, etc. So don't stress out.
[1] https://www.wildfly.org/news/2025/04/30/WildFly-Commonhaus/ and
https://www.commonhaus.org/activity/259.html
[2]
https://docs.google.com/document/d/1qak1F2caFORP2kmDFZI68NsdVkXbslvKndCbe...
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months
Move of wildscribe repo to Github wildfly org
by Brian Stansberry
I'd like to transfer the main wildscribe tool repo to the wildfly GH org
from the current 'wildscribe':
https://github.com/wildscribe/wildscribe
Then I'd like to archive the other repo in the wildscribe GH org:
https://github.com/orgs/wildscribe/repositories
I'm not 100% sure, but my guess is Stuart set up a separate org so we could
use GH Pages to publish https://wildscribe.github.io/ without burning that
site URL for the broader 'wildfly' org. But we no longer publish wildscribe
that way; now it's in the main docs set for a release, e.g.
https://docs.wildfly.org/36/wildscribe/. So we don't update the GH pages
repo and can archive it. The tool itself logically belongs in the same org
as the other main WF projects.
Please let me know if you have any concerns.
I'll likely be creating a lot of threads like this over the next month as I
do some housekeeping in preparation for the move to Commonhaus.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months, 2 weeks
Applying to Commonhaus
by Brian Stansberry
(project leads -- please be sure to read the 'If you maintain' part below.)
I'd like to take the next step in transitioning the WildFly project to a
vendor-neutral foundation by applying to Commonhaus. We've been talking
about this for quite a while, gathering input, and the consensus I've seen
has been that Commonhaus is the best option. I think Commonhaus’ guiding
principles around honoring project and community identity and offering
guidance instead of mandates, with its “community-first” governance model,
make it the best for WildFly.
The process of applying is covered at
https://github.com/commonhaus/foundation/discussions/new?category=joining....
I'm hoping to initiate a discussion by the end of this week. That entails
filling out the issue template linked above and sending up a PR with the
necessary information.
Note that I'll be applying for the 'WildFly' project, which is somewhat
nebulously defined. A simplistic, and incomplete boundary is that it covers
the non-archived projects hosted in the 'wildfly' GitHub organization. It
will also cover non-archived projects in the 'wildfly-extras' GitHub org,
except, perhaps:
creaper
sunstone
wildfly-camel
wildfly-camel-book
wildfly-camel-examples
It can cover those as well, but I want to check with the respective project
maintainers that that's what they want.
It will also cover a few repos in the 'jboss' and 'jbossas' Github orgs
that really should be moved to the 'wildfly' org.
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.
Some (not definitive) considerations as to whether a project 'fits'
* Is it somehow 'WildFly' branded, or perhaps 'JBoss' branded as a leftover
from 'JBoss AS'?
* How much is it used outside of the various WildFly deliverables?
Thanks!
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10 months, 2 weeks
