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 2012/01/30 21:11:20 UTC
2.4.1….??
Do I dare float the idea of a 2.4.1 T&R "very soon"??
Re: 2.4.1….??
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Feb 2012, at 4:47 PM, Jim Jagielski wrote:
> As I see it, we are still at the point where the stumbling block
> is 2.4.x under Windows. All other platforms, that we know of,
> seem to be OK now...
>
> How about if we give it until next Monday (Feb 6th) and if
> still no progress, we continue with the orig plan we had
> for 2.4.0: We T&R and release with a note about issues on
> Windows.
+1.
I am confident that the "4" in v2.4.1 will encourage more people to try it out, and the Windows problems will be identified and solved.
Regards,
Graham
--
Re: 2.4.1….??
Posted by Jim Jagielski <ji...@jaguNET.com>.
As I see it, we are still at the point where the stumbling block
is 2.4.x under Windows. All other platforms, that we know of,
seem to be OK now...
How about if we give it until next Monday (Feb 6th) and if
still no progress, we continue with the orig plan we had
for 2.4.0: We T&R and release with a note about issues on
Windows.
On Jan 30, 2012, at 3:11 PM, Jim Jagielski wrote:
> Do I dare float the idea of a 2.4.1 T&R "very soon"??
>
Re: 2.4.1….??
Posted by Jim Jagielski <ji...@apache.org>.
On Jan 31, 2012, at 5:04 PM, Stefan Fritsch wrote:
> r1233882 should probably be backported, too, but is unrelated.
>
I agree with the above... This resolves an issue I observed.
Re: 2.4.1….??
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 31 January 2012, Rainer Jung wrote:
> On 30.01.2012 21:11, Jim Jagielski wrote:
> > Do I dare float the idea of a 2.4.1 T&R "very soon"??
>
> I'm done with flodding the list with trivial backports.
>
> Still open are:
>
> A) Testing/Fixing the "bucket problems". There were two bugs, and I
> have lost the overview, how the fixes are related. One was the
> problem noted under Windows when SSL was failing due to an early
> read failure (BZ 5476), one was the problem noted by Joe about
> reading whole CGI/PIPE-like mutating bucket types into RAM.
The CGI/PIPE-like mutating bucket bug should now be completely fixed
in 2.4, as I have just backported r1234899.
r1233882 should probably be backported, too, but is unrelated.
The other changes (including my patch proposed on the list) are just
fixing a broken API but should not result in observable behavior
change. I don't think that they will help with the Windows/SSL issue.
> There is the patch proposed by Stefan for trunk. For 2.4.x there
> are some backports missing in addition. I guess all of the
> following would be needed for 2.4.x (plus Stefan's patch):
>
> -------------------------------------------------------------------
> ----- r1236122 | rpluem | 2012-01-26 11:03:36 +0100 (Thu, 26 Jan
> 2012) | 1 line
>
> * Don't typedef twice (in .c and .h file).
> -------------------------------------------------------------------
> ----- r1233882 | jorton | 2012-01-20 13:41:18 +0100 (Fri, 20 Jan
> 2012) | 4 lines
>
> * server/core_filters.c (ap_core_input_filter): Only treat EAGAIN
> as success if a non-blocking read was requested; for a blocking
> read, it is an error condition.
>
> -------------------------------------------------------------------
> ----- r1234899 | jorton | 2012-01-23 17:57:07 +0100 (Mon, 23 Jan
> 2012) | 4 lines
>
> * server/core_filters.c (send_brigade_nonblocking): Use a
> non-blocking bucket read, allowing any pending data to be flushed
> before trying a (potentially slow) blocking read.
>
> -------------------------------------------------------------------
> ----- r1235019 | sf | 2012-01-23 22:58:42 +0100 (Mon, 23 Jan 2012)
> | 6 lines
>
> Make the core input/output filter contexts private and provide
> accessor APIs for mpm_winnt and mod_ftp.
>
> This allows to add members to the context structs without breaking
> binary compatibility.
>
> -------------------------------------------------------------------
> -----
>
>
> B) further open stuff from STATUS:
>
> * Docs about building / installing are not up to date.
>
> * PR 52402: balancer crash on Windows
>
>
> C) some of the points in the separate "Questions" mail thread. I
> don't see a shot stopper there, but some points should be easy:
>
>
> 1) mod_reqtimeout: not a showstopper, but would be good to have
> consensus about preferred behaviour so we do not need change
> defaults dramatically after GA.
>
> 2) log tags: I hope Stefan will tell us, whether we should backport
> the make targets and the tags directory in docs/.
>
> 3) Recent install optimization: again I would rely on Stefan
> whether he thinks the changes are safe. It is only about the build
> system, so could be backported after GA.
I have reverted 1) in trunk. Only a small part of 2) should go into
2.4, but that can wait. 3) should see some more testing before
backporting.
> 5) mod_authnz_ldap: I hope Eric can comment on that one.
>
> 8) ErrorLog directory checking: Could be backported later, but
> changes behaviour under error conditions, so maybe better to
> include now unless Stefan thinks it is a risk. I think Stefan was
> aksing for Windows testers here.
>
> 4) and 7) are already done, 6) [cache] seems to be consensus for
> not changing and 9) [event] seems to be OK as is.
8) Is now done, too. This leaves only 5) from Rainer's list.
Re: 2.4.1….??
Posted by Rainer Jung <ra...@kippdata.de>.
On 30.01.2012 21:11, Jim Jagielski wrote:
> Do I dare float the idea of a 2.4.1 T&R "very soon"??
I'm done with flodding the list with trivial backports.
Still open are:
A) Testing/Fixing the "bucket problems". There were two bugs, and I have
lost the overview, how the fixes are related. One was the problem noted
under Windows when SSL was failing due to an early read failure (BZ
5476), one was the problem noted by Joe about reading whole
CGI/PIPE-like mutating bucket types into RAM.
There is the patch proposed by Stefan for trunk. For 2.4.x there are
some backports missing in addition. I guess all of the following would
be needed for 2.4.x (plus Stefan's patch):
------------------------------------------------------------------------
r1236122 | rpluem | 2012-01-26 11:03:36 +0100 (Thu, 26 Jan 2012) | 1 line
* Don't typedef twice (in .c and .h file).
------------------------------------------------------------------------
r1233882 | jorton | 2012-01-20 13:41:18 +0100 (Fri, 20 Jan 2012) | 4 lines
* server/core_filters.c (ap_core_input_filter): Only treat EAGAIN as
success if a non-blocking read was requested; for a blocking read,
it is an error condition.
------------------------------------------------------------------------
r1234899 | jorton | 2012-01-23 17:57:07 +0100 (Mon, 23 Jan 2012) | 4 lines
* server/core_filters.c (send_brigade_nonblocking): Use a non-blocking
bucket read, allowing any pending data to be flushed before trying a
(potentially slow) blocking read.
------------------------------------------------------------------------
r1235019 | sf | 2012-01-23 22:58:42 +0100 (Mon, 23 Jan 2012) | 6 lines
Make the core input/output filter contexts private and provide accessor
APIs for mpm_winnt and mod_ftp.
This allows to add members to the context structs without breaking
binary compatibility.
------------------------------------------------------------------------
B) further open stuff from STATUS:
* Docs about building / installing are not up to date.
* PR 52402: balancer crash on Windows
C) some of the points in the separate "Questions" mail thread. I don't
see a shot stopper there, but some points should be easy:
1) mod_reqtimeout: not a showstopper, but would be good to have
consensus about preferred behaviour so we do not need change defaults
dramatically after GA.
2) log tags: I hope Stefan will tell us, whether we should backport the
make targets and the tags directory in docs/.
3) Recent install optimization: again I would rely on Stefan whether he
thinks the changes are safe. It is only about the build system, so could
be backported after GA.
5) mod_authnz_ldap: I hope Eric can comment on that one.
8) ErrorLog directory checking: Could be backported later, but changes
behaviour under error conditions, so maybe better to include now unless
Stefan thinks it is a risk. I think Stefan was aksing for Windows
testers here.
4) and 7) are already done, 6) [cache] seems to be consensus for not
changing and 9) [event] seems to be OK as is.
Regards,
Rainer