4:45 p.m.
(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
4:06 a.m.
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. 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.
[1] https://github.com/hal
11:57 a.m.
On Thu, Mar 13, 2025 at 4:06 AM Harald Pehl <hpehl(a)redhat.com> wrote:
> 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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
4:24 a.m.
On Wed, Mar 12, 2025 at 9:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
(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.
I would also like to propose we consider the projects under the
wildfly-security organisation in GitHub and even wildfly-security-incubator
with the last being more of an experimental separation than true
independendence.
For WildFly Elytron and our related projects (elytron-web, elytron-ee,
elytron-mp) the reason these projects came into existence were to meet the
security needs of WildFly for the future. However these projects have been
developed to be usable independently of WildFly and there are some cases
where that happens but I don't think that would prevent them coming to a
foundation with WildFly.
At the same time we would not make any changes to these projects to make
them less relevant outside of WildFly.
Then another group of projects under wildfly-security are for WildFly
OpenSSL, again primarily developed to meet a need in WildFly but developed
using standard security provider APIs to enable use anywhere.
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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
12:01 p.m.
On Thu, Mar 13, 2025 at 4:24 AM Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
On Wed, Mar 12, 2025 at 9:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> (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.
>
I would also like to propose we consider the projects under the
wildfly-security organisation in GitHub and even wildfly-security-incubator
with the last being more of an experimental separation than true
independendence.
For WildFly Elytron and our related projects (elytron-web, elytron-ee,
elytron-mp) the reason these projects came into existence were to meet the
security needs of WildFly for the future. However these projects have been
developed to be usable independently of WildFly and there are some cases
where that happens but I don't think that would prevent them coming to a
foundation with WildFly.
At the same time we would not make any changes to these projects to make
them less relevant outside of WildFly.
Then another group of projects under wildfly-security are for WildFly
OpenSSL, again primarily developed to meet a need in WildFly but developed
using standard security provider APIs to enable use anywhere.
If this is what the Elytron team wants, it sounds good to me.
We need to revamp WildFly project governance, and having things like this
incorporated will bring an interesting dimension to that.
>
> 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
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
4:38 a.m.
Hi,
I think the metadata project under the jboss org should move (just adding it there to make
sure).
I was wondering about https://github.com/jms-ra/generic-jms-ra/ which we use and maintain
but can be used out of WildFly.
And there is the netty-xnio bridge which is under the xnio umbrella but is only used by
WildFly as far as I can tell.
Emmanuel
Le 12/03/2025 à 22:45, Brian Stansberry a écrit :
(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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
12:11 p.m.
On Thu, Mar 13, 2025 at 4:39 AM Emmanuel Hugonnet <ehugonne(a)redhat.com>
wrote:
Hi,
I think the metadata project under the jboss org should move (just adding
it there to make sure).
+1
I was wondering about https://github.com/jms-ra/generic-jms-ra/ which we
use and maintain but can be used out of WildFly.
If you want it to fit, I think it does. There are other things that to me
very much fit, e.g. JBoss DMR, that can be useful elsewhere.
And there is the netty-xnio bridge which is under the xnio umbrella but is
only used by WildFly as far as I can tell.
I'll gladly defer to you folks who work on XNIO stuff. :) I think it fits
if you want it to.
Emmanuel
Le 12/03/2025 à 22:45, Brian Stansberry a écrit :
> (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
>
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
6:50 a.m.
On Wed, Mar 12, 2025 at 9:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
(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.
About https://github.com/jboss/jboss-common-beans:
You did not mention the specific list, and since it is under the jboss
category, it is not relevant for your call. So I only wanted to know
whether it is included in such a list. For now, I assume it will.
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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
12:07 p.m.
On Thu, Mar 13, 2025 at 6:50 AM Yeray Borges Santana <yborgess(a)redhat.com>
wrote:
On Wed, Mar 12, 2025 at 9:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> (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.
>
>
About https://github.com/jboss/jboss-common-beans:
You did not mention the specific list, and since it is under the jboss
category, it is not relevant for your call. So I only wanted to know
whether it is included in such a list. For now, I assume it will.
I think it makes sense, if the maintainers do.
When I look at the 'jboss' org, this and JBoss Metadata are the two that
seem like fits. Maybe our Jakarta EL fork as well.
> 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
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
7:31 a.m.
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?
Any objection to archiving https://github.com/jbossas/jboss-as ? (If so,
then I want to see a proper code contribution. 😁)
Carlo
11:33 a.m.
On Thu, Mar 13, 2025 at 7:31 AM Carlo de Wolf <cdewolf(a)redhat.com> 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!)
If any of the others are similar and I'm just unaware of it, please someone
let me know.
Any objection to archiving https://github.com/jbossas/jboss-as ? (If
so,
then I want to see a proper code contribution. 😁)
Makes sense to me.
Carlo
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
4:46 p.m.
On Thu, Mar 13, 2025 at 11:34 AM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
On Thu, Mar 13, 2025 at 7:31 AM Carlo de Wolf
<cdewolf(a)redhat.com> 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
5:10 p.m.
On Thu, Mar 13, 2025 at 4:47 PM David Lloyd <david.lloyd(a)redhat.com> wrote:
On Thu, Mar 13, 2025 at 11:34 AM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> On Thu, Mar 13, 2025 at 7:31 AM Carlo de Wolf <cdewolf(a)redhat.com> 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.
If you want it to go along with WildFly, I think it's fine. I'm sorry for
not stating that up front; I was kind of focused on the other ones in
'jbossas' that I *think* are 98%+ purely WF, so I pretty much assume they'd
go as part of WF. I didn't want to assume that with Threads.
I confess though that I have no idea about what the expectation is on the
Commonhaus side about this kind of thing. Step 1 is the simple application;
once we do that if they're interested in having WF I'm sure we'll talk
through these kinds of issues.
--
- DML • he/him
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
10:17 a.m.
There are the https://github.com/jbossws/ JBoss Web Services projects that
likely make sense to move with WildFly as well. Those projects are only
used within WildFly. If we could move those over too that would be great!
James R. Perkins
Principal Software Engineer
Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>
On Wed, Mar 12, 2025 at 2:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
(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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
12:03 p.m.
On Thu, Mar 13, 2025 at 10:18 AM James Perkins <jperkins(a)redhat.com> wrote:
There are the https://github.com/jbossws/ JBoss Web Services
projects
that likely make sense to move with WildFly as well. Those projects are
only used within WildFly. If we could move those over too that would be
great!
OK, if that's what's wanted. Not thinking through all the details, I think
it fits.
Similar to what I said in response to Darran, this brings some interesting
aspects to a revamped project governance.
James R. Perkins
Principal Software Engineer
Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>
On Wed, Mar 12, 2025 at 2:46 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> (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
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2:47 p.m.
Update on this:
https://github.com/commonhaus/foundation/discussions/242
https://github.com/commonhaus/foundation/pull/243
On Wed, Mar 12, 2025 at 4:45 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
(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
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
3:31 p.m.
I'm VERY pleased to inform you that WildFly's application to join
Commonhaus has been accepted!
https://github.com/commonhaus/foundation/discussions/242#discussioncommen...
I'll not get going on the "onboarding" process. As part of that we'll
need
to finalize some of the things discussed here. We'll also need to revamp
WildFly's project governance to move to a vendor-neutral model and to
better reflect how we want the project to operate. We'll definitely be
having plenty of discussions about that. (Not too much here please -- let's
try and focus here on the 'scope' aspect.)
On Mon, Mar 17, 2025 at 2:47 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
Update on this:
https://github.com/commonhaus/foundation/discussions/242
https://github.com/commonhaus/foundation/pull/243
On Wed, Mar 12, 2025 at 4:45 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> (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
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
3:34 p.m.
Congratulations
On Thu, Apr 24, 2025 at 2:32 PM Brian Stansberry via wildfly-dev <
wildfly-dev(a)lists.jboss.org> wrote:
I'm VERY pleased to inform you that WildFly's application to
join
Commonhaus has been accepted!
https://github.com/commonhaus/foundation/discussions/242#discussioncommen...
I'll not get going on the "onboarding" process. As part of that we'll
need
to finalize some of the things discussed here. We'll also need to revamp
WildFly's project governance to move to a vendor-neutral model and to
better reflect how we want the project to operate. We'll definitely be
having plenty of discussions about that. (Not too much here please -- let's
try and focus here on the 'scope' aspect.)
On Mon, Mar 17, 2025 at 2:47 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> Update on this:
>
> https://github.com/commonhaus/foundation/discussions/242
> https://github.com/commonhaus/foundation/pull/243
>
> On Wed, Mar 12, 2025 at 4:45 PM Brian Stansberry <bstansbe(a)redhat.com>
> wrote:
>
>> (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
>>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> WildFly Project Lead
> He/Him/His
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
3:21 a.m.
Congratulations to the project and team!
On Thu, 24 Apr 2025 at 21:32, Brian Stansberry via wildfly-dev <
wildfly-dev(a)lists.jboss.org> wrote:
I'm VERY pleased to inform you that WildFly's application to
join
Commonhaus has been accepted!
https://github.com/commonhaus/foundation/discussions/242#discussioncommen...
I'll not get going on the "onboarding" process. As part of that we'll
need
to finalize some of the things discussed here. We'll also need to revamp
WildFly's project governance to move to a vendor-neutral model and to
better reflect how we want the project to operate. We'll definitely be
having plenty of discussions about that. (Not too much here please -- let's
try and focus here on the 'scope' aspect.)
On Mon, Mar 17, 2025 at 2:47 PM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
> Update on this:
>
> https://github.com/commonhaus/foundation/discussions/242
> https://github.com/commonhaus/foundation/pull/243
>
> On Wed, Mar 12, 2025 at 4:45 PM Brian Stansberry <bstansbe(a)redhat.com>
> wrote:
>
>> (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
>>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> WildFly Project Lead
> He/Him/His
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
3:44 a.m.
Excellent news - Congratulations
On 24 Apr 2025, at 21:31, Brian Stansberry via wildfly-dev
<wildfly-dev(a)lists.jboss.org> wrote:
I'm VERY pleased to inform you that WildFly's application to join Commonhaus has
been accepted!
https://github.com/commonhaus/foundation/discussions/242#discussioncommen...
I'll not get going on the "onboarding" process. As part of that we'll
need to finalize some of the things discussed here. We'll also need to revamp
WildFly's project governance to move to a vendor-neutral model and to better reflect
how we want the project to operate. We'll definitely be having plenty of discussions
about that. (Not too much here please -- let's try and focus here on the
'scope' aspect.)
On Mon, Mar 17, 2025 at 2:47 PM Brian Stansberry <bstansbe(a)redhat.com
<mailto:bstansbe@redhat.com>> wrote:
> Update on this:
>
> https://github.com/commonhaus/foundation/discussions/242
> https://github.com/commonhaus/foundation/pull/243
>
> On Wed, Mar 12, 2025 at 4:45 PM Brian Stansberry <bstansbe(a)redhat.com
<mailto:bstansbe@redhat.com>> wrote:
>> (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
>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> WildFly Project Lead
> He/Him/His
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
---------------------------------------------
Mark Eastman
Middleware Engineering Director
Red Hat UK Ltd.
meastman(a)redhat.com
t: +44 (0) 191 495 7407
m: +44 (0) 791 228 1527
152
days inactive
200
days old
19 comments
11 participants
participants (11)
-
Brian Stansberry -
Carlo de Wolf -
Darran Lofthouse -
David Lloyd -
Emmanuel Hugonnet -
Harald Pehl -
James Perkins -
Mark Eastman -
Scott Stark -
Tom Jenkinson -
Yeray Borges Santana