You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2018/09/12 12:48:49 UTC
Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)
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.
Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thanks, this is useful.
At first blush, this looks like there is a crap-ton of stuff in trunk than can, and should, be quickly and easily backported to 2.4 asap!!
> On Sep 12, 2018, at 10:06 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
> 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
>
> Everything in trunk is now digested into three groups of commits, for inspection. These don't include whitespace changes, so the resulting files may be mis-indented and otherwise skewed, but we are looking for changes, not insignificant formatting;
>
> Just the docs (sources, and generated)
> http://svn.apache.org/viewvc?view=revision&revision=1840682 <http://svn.apache.org/viewvc?view=revision&revision=1840682>
> http://svn.apache.org/viewvc?view=revision&revision=1840684 <http://svn.apache.org/viewvc?view=revision&revision=1840684>
>
> Just win32 generated build gunk (presuming vcproj and CMake are both winners, there is a discussion to be had on .mak files before this gap is addressed)
> http://svn.apache.org/viewvc?view=revision&revision=1840687 <http://svn.apache.org/viewvc?view=revision&revision=1840687>
>
> Everything else (all the interesting stuff)
> http://svn.apache.org/viewvc?view=revision&revision=1840688 <http://svn.apache.org/viewvc?view=revision&revision=1840688>
>
> I expect committers will be mostly interested in the last link above.
>
Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski <ji...@jagunet.com> wrote:
> 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
Everything in trunk is now digested into three groups of commits, for
inspection. These don't include whitespace changes, so the resulting files
may be mis-indented and otherwise skewed, but we are looking for changes,
not insignificant formatting;
Just the docs (sources, and generated)
http://svn.apache.org/viewvc?view=revision&revision=1840682
http://svn.apache.org/viewvc?view=revision&revision=1840684
Just win32 generated build gunk (presuming vcproj and CMake are both
winners, there is a discussion to be had on .mak files before this gap is
addressed)
http://svn.apache.org/viewvc?view=revision&revision=1840687
Everything else (all the interesting stuff)
http://svn.apache.org/viewvc?view=revision&revision=1840688
I expect committers will be mostly interested in the last link above.
Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Sep 12, 2018 at 2:57 PM Stefan Eissing
<st...@greenbytes.de> wrote:
>
>
> > Am 12.09.2018 um 14:48 schrieb Jim Jagielski <ji...@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 :)
Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.09.2018 um 14:48 schrieb Jim Jagielski <ji...@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.
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.
Or another way: I am too old to commit to trunk only. ;)
-Stefan