<div dir="ltr">Its a high-performance connection pool written by Luis from the performance team.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 14, 2017 at 4:12 AM Rostislav Svoboda <<a href="mailto:rsvoboda@redhat.com">rsvoboda@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> + Agroal inclusion<br>
What's that ^^^ ?<br>
<br>
Thank you.<br>
Rostislav<br>
<br>
----- Original Message -----<br>
> Hello Everyone,<br>
><br>
> Release Model Changes<br>
> ————————————————————-<br>
> In order to bring new capabilities to the community quicker, we plan to move<br>
> to a more iterative time-boxed approach, starting with WildFly 12 (and<br>
> continuing with 13, 14, etc). By time-boxed, I mean the each release aims to<br>
> have a fixed and reliable delivery window that approximates a calendar<br>
> quarter. Since these time-frames are fixed, it’s important that any given<br>
> feature or improvement not hold up a release. To facilitate this we need to<br>
> make major changes to our development process. Currently development for any<br>
> enhancement is merged in chunks, as it progresses from inception to<br>
> completion. This means to have something worthy of release, we must either<br>
> block for its completion or roll it back. The latter is often difficult,<br>
> since at any given moment there are many features under active development,<br>
> and their respective implementations can become co-dependent. Additionally,<br>
> its common for component dependencies to start off as Alphas and/or Betas,<br>
> and we end up needing to wait for those components to hit Final before we<br>
> can cut the release.<br>
><br>
> The solution to this problem is to rely more on topic branches, and only<br>
> merge fully completed work to master. By fully complete, I mean all PRs on<br>
> master should be fully developed, tested, and documented[1]. Additionally<br>
> any updated dependencies must only be against Final/GA components.<br>
><br>
> This has a number of advantages:<br>
><br>
> A. Master becomes always stable, always releasable. So at any given moment we<br>
> can decided to cut a release[1]<br>
> B. Nightly builds become way more usable, and a great feedback channel (a<br>
> release starts to have less importance)<br>
> C. If a feature takes longer than expected, no big deal, it will be picked up<br>
> in the next cycle[2]<br>
> D. Should anything cause a major regression, not caught in testing it will be<br>
> easier to revert, since the history will be cleaner<br>
><br>
> Since in-progress work will need to be based on topic branches, custom jobs<br>
> on <a href="http://ci.wildfly.org" rel="noreferrer" target="_blank">ci.wildfly.org</a> will need to be relied upon instead of the automated CI<br>
> that happens when you submit a PR (although that’s still important and still<br>
> staying). Additionally if two changes/improvements are interrelated, then<br>
> they will need to either share a topic branch, or find a way to construct<br>
> the work independently (potentially adding and removing a temporary<br>
> construct until both are merged).<br>
><br>
><br>
> [1] To make it easier to associate documentation with the PR, we are looking<br>
> to move to an asciidoc based solution instead of confluence like we utilize<br>
> today.<br>
><br>
> [2] While this is generally the case, there are some activities we can’t<br>
> avoid before releasing, such as ensuring a TCK run has completed.<br>
><br>
> [3] An important aspect of C is that iterations have a short enough cycle,<br>
> such that the pressure to make a particular iteration is low enough to avoid<br>
> the urge to try and cram something in, and potentially compromise quality<br>
> (e.g. no docs etc).<br>
><br>
><br>
> Java EE8<br>
> ————————<br>
> As part of adopting this model, we aim to deliver Java EE8 in incremental<br>
> chunks. Adding support for specs individually in batches. As an example for<br>
> WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to<br>
> unfortunate restrictions in EE certification, we will need to have a<br>
> separate configuration profile or property to enable these additional APIs<br>
> until we complete full EE8 certification.<br>
><br>
> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]<br>
> ————————————————————————<br>
> + Adopt new release model<br>
> + Java 9 improvements<br>
> + Servlet 4<br>
> + JSON-B (incorporating Yasoon)<br>
> + CDI 2<br>
> + JSF 2.3<br>
> + Metaspace usage improvements<br>
> + early/initial changes to accommodate the new provisioning effort (easy<br>
> slimming, updates, etc)<br>
><br>
> Proposed WildFly 13 Goals (Very Tentative) [May 2018]<br>
> ———————————————————————————-<br>
> + New EE Security Spec<br>
> + Adoption of provisioning<br>
> + JPA 2.2<br>
> + JAX-RS 2.1<br>
> + BV 2.0<br>
> + Agroal inclusion<br>
><br>
> Just to highlight that with this new model, that these goals I am proposing<br>
> are not something we would block on, any given item might be deferred to the<br>
> next release if it’s not quite ready. Let me know if you have any additional<br>
> major items you are planning to contribute towards 12.<br>
><br>
> Thanks!<br>
><br>
> -Jason<br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div>