Last December I posted[1] about the WildFly Feature Development Process we're implementing. We understand a lot about what that should look like, but there are still details to clarify. I think the consensus among the folks who've been looking at it most is that the best way to progress on doing that is by actually implementing some features at Community, Preview or Experimental levels and using the work on those to help firm up the details.
When we rolled this out in December it was really too late to do much of that for WildFly 31, except for one feature[2] that Emmanuel Hugonnet did. But it's not too late to do this for WildFly 32, and I know there are a number of features that are in various states of development that could likely benefit from the new process and could thereby be included in next month's WildFly 32 Beta.
I'll list a number of possible candidates below, but there may very well be others.
ACTION REQUEST: If you have worked on a feature that you'd like included in WF 32 at Community, Preview or Experimental, please do the following as soon as possible:
1) Decide what level you think is achievable in a month's time. If you're not sure, ask about it in this thread or another wildfly-dev list thread, or in zulip.
2) Update the analysis document for your feature with the 'Stability Level' section I added to the proposal template.[3] Tick the appropriate box.
3) Preface the title of the relevant WFLY or WFCORE with [Community], [Preview] or [Experimental]. (This is so this info is prominent in future release notes.)
4) Preface the feature title (the "= Foo" line) in the analysis adoc file with [Community], [Preview] or [Experimental]. (This is so this info is prominent in future views of https://docs.wildfly.org/wildfly-proposals/)
5) Add 32.0.0.Beta1 as the Fix Version for the JIRA.
6) Look at the draft process at [4] and start working on completing the requirements! Ask questions on this list or zulip to get clarification on things.
Please use the list or preferably zulip instead of pinging me personally. We need to work through this as a group and learn from each other.
Here are the features we thought were likely candidates for the new process *at some point*. AFAIK no one thought much about whether they could be done in time for WF 32. The devs working them know better about that. But, please try and be realistic. :) All features require involvement from multiple people. And again, there may be other good candidates as well; don't be shy.
These are in no particular order.
* WFCORE-4807 - Add option to route log messages based on the current thread's class loader
* WFLY-13762 - SSLContext to support delegation to alternate instances based on peer information.
* WFLY-14559 - Add four new RESTEasy context parameters
* WFLY-14735 - Add support with the web console for FORM based authentication resulting in an authenticated session.
* HAL-1831 - Activate form-based authentication in the console
* WFLY-15495 - Add support for gRPC
* WFLY-13530 - REST Integration with grpc (high performance, open-source universal RPC framework)
* WFLY-16345 - Add support for SFSB externalization to remote Infinispan server via HotRod
* WFLY-13412 - Add Json Merge Patch support
* WFCORE-4868 - Introduce aliases for standard configuration files
* WFCORE-5279 - Split Elytron SSL into its own subsystem and layer
* WFLY-13828 - remote+tls is not supported by EJBClient and remote-outbound-connection
* WFLY-15452 - Modify ajp-listener to allow specifying AJP_ALLOWED_REQUEST_ATTRIBUTES_PATTERN
* WFLY-14255 - Make reuseXForwarded and rewriteHost configurable
* WFLY-17676 - Add a configuration for enabling EE namespace interoperability
* WFLY-17180 Failure to set query timeout for validation may result in long blocks of the pool
Note that my emphasis here is on WF 32, but it's ok to start on this with features where you may not think getting done by the March 20 feature freeze is realistic, particularly the 'pick a target stability level and record it in JIRA and analysis' tasks I mentioned above. Just be conscious that answering your questions etc may be a lower priority over these next few weeks.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His