On Wed, Sep 12, 2018 at 2:57 PM Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > > > Am 12.09.2018 um 14:48 schrieb Jim Jagielski <j...@jagunet.com>: > > > > As I said before, the main assumption in my suggestion is that there are > > things in trunk that "really should" be in some releasable version, stuff > > significant enough to warrant the work, but is "impossible" to be > > backported to 2.4. > > > > If there are no real significant-but-impossible-to-backport features in > > trunk, then the proposal itself is moot. > > > > So let's think about it: What is currently in trunk that is a pretty > > significant improvement? Then ask if it is directly backportable. Certainly > > the effort in backporting from trunk to 2.4.x is much less than the effort > > in spinning out 2.6.x and considering all things, that should be the > > primary flow. > > There are things I'd like to do for 2.5.x-to-become-2.6 releases that I > cannot to in 2.4.x and will not do before that. I assume this holds also true > for others.
+1 FWIW I've got WIP on async mod_proxy_http (based on wstunnel/event "go async" mode, with common functions put in proxy_util, the pump/forward loop from PR 61616, websocket proxying friendly). Of course I'll propose it on dev@ first, and if it's received positively that could make great stuff for 2.6, but not for 2.4 where modules are not really prepared to be changed their running thread underneath them... > > To put it another way: current trunk is dead code to me. Only a stopover for > 2.4.x (aka release version). For the last three years, it was just in the way. That can't/shouldn't be, trunk is where we do improvements AND the next released version. Once we take less care of 2.4 compat, things become much easier IMHO. > > Or another way: I am too old to commit to trunk only. ;) I'm sure that trunk + all of your (and others) pending stuff made to 2.6 and you go for a new youth :)
