Hi, in the context of this Issue: https://github.com/wildfly/wildfly-proposals/pull/627 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(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...

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(a)redhat.com&gt; 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(a)redhat.com&gt; > wrote: > >> Hi, >> in the context of this Issue: >> https://github.com/wildfly/wildfly-proposals/pull/627 >> 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(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 >