Yes, it works for me! By the way, what do you think about merging/completing the review for this PR before the branch cut for RC1? https://github.com/apache/storm/pull/8819 Let me know if you think it's ready and safe to include.
Thanks! - Gianluca Il giorno mer 15 lug 2026 alle ore 15:26 Richard Zowalla < [email protected]> ha scritto: > I dont mind either way ;-) > > > Am 15.07.2026 um 15:00 schrieb Rui Abreu <[email protected]>: > > > > Gianluca, @Richard Zowalla can we get some votes on getting 3.0.0 RC1 > > and 2.8.9 RC1 out? > > > >> On Sun, 12 Jul 2026 at 11:55, Julien Nioche > >> <[email protected]> wrote: > >> > >>> I propose we release 2.8.9 with 3.0.0 and warn the community that 2.x > >> is EOL and that it's the last release. 2.8.9 contains a few > >> dependabots upgrades compared to 2.8.8, so it's worth doing. > >> > >> + 1 from me. > >> > >> Julien > >> > >>> On Sat, 11 Jul 2026 at 21:26, Rui Abreu <[email protected]> wrote: > >>> > >>> Note: we recently released 2.8.8 so the title of this email chain is > >>> wrong. It should read 2..8.9. > >>> > >>> While keeping 2.x alive for some time is appealing, the jump from > >>> Storm 2 to 3 is much less complex than the one made from Storm 2 to 3. > >>> Even with master (Storm 3) shipped with Java 25 > >>> We should focus our attention and resources on 3.x, which has quite a > >>> few interesting new additions. > >>> I propose we release 2.8.9 with 3.0.0 and warn the community that 2.x > >>> is EOL and that it's the last release. 2.8.9 contains a few > >>> dependabots upgrades compared to 2.8.8, so it's worth doing. > >>> > >>> On Wed, 8 Jul 2026 at 21:48, Gianluca Graziadei > >>> <[email protected]> wrote: > >>>> > >>>> I agree that setting an EOL for 2.X is a natural next step for the > >>>> project, and options b1 or b2 seem like the best approach. > >>>> > >>>> Cheers, > >>>> Gianluca > >>>> > >>>> > >>>> On Wed, 8 Jul 2026, 10:04 Rui Abreu, <[email protected]> wrote: > >>>> > >>>>> I agree @Richard Zowalla .The sooner the better, to let the community > >>>>> manage expectations > >>>>> > >>>>> Do you want me to set up the vote? > >>>>> > >>>>> On Wed, 8 Jul 2026 at 07:48, Richard Zowalla <[email protected]> > wrote: > >>>>>> > >>>>>> Yes. We should open a discussion / vote with different options for > >>>>> EOLing 2.x (since resources to maintain 2.x branches and getting the > >>> votes > >>>>> needed for a release are quite sparse). > >>>>>> > >>>>>> Think primary questions for that would be: > >>>>>> > >>>>>> (a) Do we have consensus that such an EOL announcement is long > >>> overdue > >>>>> and should be put out rather soonish? > >>>>>> (b) Time of the announcement: Options that I see: > >>>>>> - b1: Directly with the projected release of the 3.0.0 marking it as > >>> the > >>>>> last release ever to be expected for OpenNLP 2.x > >>>>>> - b2: Shortly after - with a grace period - for instance End of Year > >>>>> 2026, or similar short ranged targets. > >>>>>> - b3: Mid of year 2027 > >>>>>> > >>>>>> Gruß > >>>>>> Richard > >>>>>> > >>>>>> On 2026/07/07 22:44:52 Rui Abreu wrote: > >>>>>>> Created this PR https://github.com/apache/storm/pull/8893 to set > >>> the > >>>>>>> baseline as Java 25. > >>>>>>> Additionally, we should vote on setting Apache Storm 2.x as EOL > >>> (it is > >>>>>>> only receiving dependabot updates at this point) > >>>>>>> > >>>>>>> Thank you > >>>>>>> > >>>>>>> On Mon, 29 Jun 2026 at 14:34, Richard Zowalla <[email protected]> > >>> wrote: > >>>>>>>> > >>>>>>>> +1 on thinking about Java 25 for 3.0.0 rather than just bumping > >>> to > >>>>> 21. > >>>>>>>> > >>>>>>>> The reason it is worth it now is the pinning fix: JEP 491 > >>>>> ("Synchronize Virtual Threads without Pinning"), delivered in Java 24 > >>> and > >>>>> carried into the 25 LTS. Before that, in 21 to 23, a virtual thread > >>> that > >>>>> blocked on I/O inside a synchronized block stayed pinned to its > carrier > >>>>> thread, and under load that could exhaust the carrier pool and stall > >>>>> progress. That is a real concern for us, because we have a fair > amount > >>> of > >>>>> synchronized code sitting in exactly the I/O bound paths where you > >>> would > >>>>> want to use VTs. On 24/25 the VT unmounts and frees the carrier while > >>> it > >>>>> waits, so we would not have to go and rewrite every synchronized > block > >>> as > >>>>> ReentrantLock first, which is the migration a lot of libraries had to > >>> do > >>>>> (MySQL Connector/J, Resilience4j and others). Native/JNI is the one > >>>>> remaining pinning case, but that is narrow. > >>>>>>>> > >>>>>>>> Where this could actually matter in Storm: the places that spend > >>>>> their time waiting rather than computing are the obvious candidates. > >>>>> Netty/transport worker connections, external lookups in bolts (DB, > >>> HTTP, > >>>>> cache), and the various ack/metrics/heartbeat paths that talk to > >>>>> ZooKeeper/Nimbus. These are classic thread-per-connection or > >>> bounded-pool > >>>>> setups today, and a thread-per-task VT model could simplify them and > >>> scale > >>>>> better when a topology fans out to a lot of blocking calls > >>>>>>>> . > >>>>>>>> What we would want to be careful about: the hot path is the > >>>>> executor's disruptor queues and the spout/bolt processing loop, and a > >>> lot > >>>>> of that is CPU bound message passing, not blocking I/O, so VTs do not > >>> help > >>>>> there and should not be forced in. This is about targeted use in the > >>> I/O > >>>>> bound corners, not running everything on virtual threads. We would > also > >>>>> want to watch ThreadLocal usage, since Scoped Values (finalised in > 25) > >>> are > >>>>> the intended replacement and we lean on thread locals in a few spots. > >>>>>>>> > >>>>>>>> So my argument is: if we are doing a new major anyway, baselining > >>>>> 3.0.0 on Java 25 rather than 21 costs us little extra now and saves a > >>>>> second baseline bump later. It also keeps the door open to actually > >>> explore > >>>>> VTs in the blocking paths. > >>>>>>>> > >>>>>>>> Realistically it will be a good while before we are in a > >>> position to > >>>>> do a Storm 4, so 3.x is where any of this experimentation has to live > >>>>> regardless, and I would rather not start that line on a baseline we > >>> already > >>>>> know we will want to move off. > >>>>>>>> > >>>>>>>> I am not saying we commit to adopting VTs in 3.0.0 itself. Just > >>> that > >>>>> 25 as the baseline is the enabler, and we can prototype on a branch > >>> from > >>>>> there. > >>>>>>>> > >>>>>>>> Gruß > >>>>>>>> Richard > >>>>>>>> > >>>>>>>> On 2026/06/24 13:24:26 Rui Abreu wrote: > >>>>>>>>> Julien, master is being compiled with JDK 21, but our test > >>>>> pipelines > >>>>>>>>> run both 21 and 25. > >>>>>>>>> > >>>>>>>>> On Wed, 24 Jun 2026 at 10:49, Julien Nioche > >>>>>>>>> <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Rui, > >>>>>>>>>> > >>>>>>>>>> Are we moving to Java 25 in 3.x? > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> > >>>>>>>>>> Julien > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mon, 22 Jun 2026 at 14:57, Rui Abreu <[email protected] > >>>> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hey folks, > >>>>>>>>>>> > >>>>>>>>>>> We have several good contributions in master and a few more > >>>>> undergoing PRs. > >>>>>>>>>>> I'm keen on releasing 3.0.0 to the community soon. I don't > >>>>> mind at all > >>>>>>>>>>> doing the release. > >>>>>>>>>>> > >>>>>>>>>>> Let me know what you think > >>>>>>>>>>> > >>>>>>>>>>> On Wed, 20 May 2026 at 19:02, Rui Abreu < > >>> [email protected]> > >>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Totally agree. I would say we should keep merging > >>> dependabot > >>>>> PRs into > >>>>>>>>>>>> 2.x for some months, but only do a release if we have > >>>>> reports of a > >>>>>>>>>>>> bug, like the one we patched in 2.8.8. > >>>>>>>>>>>> Otherwise, 3.0.0 will be the way to go to better utilise > >>> our > >>>>> manpower > >>>>>>>>>>> resources. > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, 20 May 2026 at 18:38, Richard Zowalla < > >>>>> [email protected]> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Given our current man power it might be beneficial, if > >>> we > >>>>> decide on a > >>>>>>>>>>>>> EOL strategy for the 2.x release line before going into > >>>>> 3.x (dropped > >>>>>>>>>>>>> clojure, Java 21 baseline), so we have a clear way on > >>> how > >>>>> long we want > >>>>>>>>>>>>> to support the 2.x branch with releases. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Given our slow pace in getting the required votes, we > >>>>> might have an > >>>>>>>>>>>>> issue with maintaing to release lines in parallel over > >>> a > >>>>> longer period > >>>>>>>>>>>>> of time. Think we can do that for a few months but not > >>>>> endlessly. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Might be worth a discussion thread on the dev@ list. > >>> wdyt? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Am Mittwoch, dem 20.05.2026 um 16:44 +0100 schrieb Rui > >>>>> Abreu: > >>>>>>>>>>>>>> Hello @Richard Zowalla > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We can consider releasing 3.0.0 over the next week > >>> or so. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Sun, 10 May 2026 at 23:09, Rui Abreu < > >>>>> [email protected]> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks for the PRs @Richard Zowalla , much > >>> appreciated. > >>>>>>>>>>>>>>> I have merged them and dealt with the subsequent > >>>>> dependabot > >>>>>>>>>>>>>>> avalanche. > >>>>>>>>>>>>>>> Apologies if you received a whole bunch of Jenkins > >>>>> errors. > >>>>>>>>>>>>>>> I was using AI + GH client to deal with the > >>> dependabot > >>>>> PRs in > >>>>>>>>>>>>>>> batches > >>>>>>>>>>>>>>> and it was being quite helpful, right up until the > >>>>> point and it > >>>>>>>>>>>>>>> decided to merge a few PRs whose tests were still > >>>>> ongoing > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> problematic Merges > >>>>>>>>>>>>>>> * #8632 (Jersey 4.0.2 upgrade on 2.x) > >>>>>>>>>>>>>>> * #8615 (Checkstyle 13.4.2 on master) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Both have been reverted and both master and 2.x > >>> are ok. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'll create a RC for 2.8.8 during the week. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Sun, 10 May 2026 at 17:01, Rui Abreu < > >>>>> [email protected]> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Ok, we can hold off on 3.0.0 for now. > >>>>>>>>>>>>>>>> I'll focus on making sure 2.8.8 has the necessary > >>>>> changeset and > >>>>>>>>>>>>>>>> then we can get the RC going. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Sun, May 10, 2026, 16:58 Richard Zowalla < > >>>>> [email protected] > >>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 2.8.8 is fine for me. Guess we need to > >>> confirmed > >>>>> dependabot for > >>>>>>>>>>>>>>>>> 2.x branches too (+ license update action) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 3.0.0 would need the Java 21 bump before (as > >>>>> discussed in the > >>>>>>>>>>>>>>>>> related discussion - dont know if there are > >>> other > >>>>> things like > >>>>>>>>>>>>>>>>> the Jitter RFC stuff for it) - perhaps there is > >>>>> something else. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Gruß > >>>>>>>>>>>>>>>>> Richard > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Am 10.05.2026 um 17:13 schrieb Rui Abreu < > >>>>> [email protected] > >>>>>>>>>>>> : > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi folks, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Just trying to understand if you are keen on > >>>>> performing a > >>>>>>>>>>>>>>>>>> release for both > >>>>>>>>>>>>>>>>>> versions shortly > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> *Julien Nioche * > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> digitalpebble.com <http://www.digitalpebble.com/> > >>>>>>>>> > >>>>>>> > >>>>> > >>> > >> > >> > >> -- > >> *Julien Nioche * > >> > >> > >> digitalpebble.com <http://www.digitalpebble.com/> >
