We talked a bit about this today and I think we agreed that 'incubating' is fine. I think my 'feature packs that are not at all incubating from the POV of their authors' concern was overthinking it. And in any case it's the WildFly project that decides whether we consider something to be incubating.

On Wed, Oct 30, 2024 at 12:17 PM Jean Francois Denise <jdenise@redhat.com> wrote:
Thank-you Brian,
I agree, using "experimental" is misleading. A feature-pack that would contain experimental features, without any stable contract, following the WildFly Community Feature Process, should be included in the "default" space. The stability level used as a Glow parameter could be used to enable the features lower than community for feature-packs inside this group.
The space name for the "outsiders" feature-packs should reflect this "outside of the WildFly feature process" notion. "external" could be such a name. I was also thinking of "extra" but it could be misleading with the "wildfly-extra" github organization.
Suggestions are welcome.
Thank-you.
JF


On Fri, Oct 25, 2024 at 10:41 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
I wonder if we'd be better off using a different term than 'experimental'. I don't know if there's a 1:1 relationship between server stability levels and the potential categories of feature packs. Using a feature stability level name as a term implies there is.

A clear dividing line I see is whether the developers behind a feature pack are carefully following the WF Community Feature Process or not. If they are, then the feature pack can include elements at all sorts of stabilities, as 'wildfly-ee' itself does.

I've used the term 'incubating' before, but that's not quite right either. There can be feature packs that are not at all incubating from the POV of their authors, but their development is not following or cannot be confirmed to be following our processes.


On Wed, Oct 16, 2024 at 3:45 AM Jean Francois Denise <jdenise@redhat.com> wrote:
Hi,
we are defining a solution to allow for WildFly Glow to discover and suggest Galleon feature-packs and layers defined in other spaces than the default space (the current location in which feature-packs are registered).

The introduction of these spaces should help feature-pack developers to follow the WildFly Feature Development Process. A feature-pack would be able to migrate from spaces to spaces to finally reach the community stability level and be discovered by WildFly Glow by default.
 
The first space we plan to define is the 'experimental' space. A space that would contain feature-packs in active development.
A first candidate to be registered in this space could be the WildFly AI feature-pack (https://github.com/wildfly-extras/wildfly-ai-feature-pack) that is currently actively developed.

Thank-you.
JF

_______________________________________________
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/TIHXKILBIMDGRL3XS7P2CNCJC7IMWCFE/


--
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