[wildfly-dev] Need Your Help! (WF8 Post Release Work)

[Jason Greene]

Hi Everyone,

Thanks again for all of your efforts on 8, the release appears to be well received. I know some of you are already looking at 9, but as I mentioned before the release, I’m hoping we can all focus on helping the community and fixing 8 issues. 

Here is some things you can do to help WF8 be a success:

1. Help our users on the forums, and translate to JIRA as necessary - We have more activity now that more people are kicking the tires. Let’s keep them engaged and make sure they feel welcome!

2. Fix the popular bugs - It would be fantastic if we can clean up any discovered problems in a short time frame, by getting those fixes into 8.0.1.

3. Blog - Helping our new users get familiar with some of the new capabilities is a great way to build interest. If you like, we can also post your blog entry on WildFly.ORG. All it takes a PR, but if you need help get the content written and ping me.

4. Docs/Wikis - If everyone could double check our current docs in their area of expertise, and make sure they are helpful and up to date that would be awesome. If you see frequent common questions on the forums, creating an informative wiki would be a great aid

5. JUG talks - A number of you have already done this, but in case some of you aren’t aware, Arun is organizing WildFly overview talks with various JUGs that have expressed interest. There is a presentation ready to go (that you can customize), and its all virtual (over Google Hangout). Ping him if you are interested in this.

6. Encourage contributors - Sometimes our users are willing or interested in contributing, but don’t really know how to do it, or maybe just need to know their expertise is desired. If you see someone digging into things deeply, ask if they are interested in fixing it and offer to help them through the process.

Here are some major things that we noticed after 8 that need looking into:

1. Our default configuration has some less optimal values. This is mostly because we specify way too much up-front. One of our original yet not fully realized goals, is that any parameter which varied according to system capacity would have an auto-set intelligent default. Things like thread pool sizes should be a ratio of the number of available processors. Memory based limits should be calculated based on available max memory. Also we should avoid specifying things that we may later want to change. As an example we might set an explicit path in our config file, and there really is no reason why we want to do this other than to inform users the option exists. Ideally that should be a default, which can be changed after a patch, and any specified value would actually be the intention of the user.

2. Console needs slimming. The recent thread on that was a very useful discussion, and I think 8.0.1 is a great place to introduce the slimmed console.

3. OpenShift. We should double check there are no open shift issues we need to address before 8.0.1. There was a thread about JMS configuration issues, and I think we should revisit those.

If anyone has any other items to raise, now is the time.

Thanks!

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat