Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of steve.m.hay@googlemail.com
 designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <537328D8.9020001@redhat.com>
References: <534F78C8.1000902@redhat.com>
	<CADED=K4yLnGJpukbTfCjh0TxFy-Mg0KkdoNs01BiTGMjx7tosA@mail.gmail.com>
	<535F81AA.6060801@redhat.com>
	<CADED=K6D79tnfKRMtRQckMS1EH3sG73bV7tsh8P9_q2Ay0-z6A@mail.gmail.com>
	<537328D8.9020001@redhat.com>
Date: Wed, 14 May 2014 13:07:47 +0100
Message-ID: 
 <CADED=K6ALvu3oiuAaVmRG+qVgP1_HnbB=MNi0Pa01mvGJf49vA@mail.gmail.com>
Subject: Re: Current httpd24threading branch problems?
From: Steve Hay <steve.m.hay@googlemail.com>
To: =?UTF-8?Q?Jan_Kalu=C5=BEa?= <jkaluza@redhat.com>
Cc: mod_perl Dev <dev@perl.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 14 May 2014 09:27, Jan Kalu=C5=BEa <jkaluza@redhat.com> wrote:
> On 05/13/2014 07:29 PM, Steve Hay wrote:
>>
>> On 29 April 2014 11:40, Jan Kalu=C5=BEa <jkaluza@redhat.com> wrote:
>>>
>>> On 04/17/2014 09:15 AM, Steve Hay wrote:
>>>>
>>>>
>>>> On 17 April 2014 07:46, Jan Kalu=C5=BEa <jkaluza@redhat.com> wrote:
>>>>>
>>>>>
>>>>> Hi Fred,
>>>>>
>>>>> could you please sum up what's the current state of httpd24threading
>>>>> branch?
>>>>> I think you're the only one currently who knows what has to be done
>>>>> before
>>>>> we can release it somehow.
>>>>>
>>>>> I've tried to read the mailing list to refresh my memory, but I'm not
>>>>> sure
>>>>> what has been fixed/done already during these 3 months.
>>>>>
>>>>
>>>> I think it's mostly been me and you working on it, actually!
>>>>
>>>> I've said before that I need to fix some Windows test failures and
>>>> then (assuming *nix doesn't have any outstanding of its own) I'll be
>>>> happy to merge this branch into trunk and we can get a release going.
>>>>
>>>> My current list of failures is:
>>>>
>>>> Test Summary Report
>>>> -------------------
>>>> t\compat\conn_rec.t                   (Wstat: 0 Tests: 2 Failed: 0)
>>>> [new failure for 2.4.x]
>>>>     Parse errors: Bad plan.  You planned 4 tests but ran 2.
>>>> t\modperl\local_env.t                 (Wstat: 0 Tests: 6 Failed: 1)
>>>>     Failed test:  6
>>>> t\modperl\merge.t                     (Wstat: 0 Tests: 10 Failed: 3)
>>>>     Failed tests:  3, 6, 9
>>>> t\modperl\merge2.t                    (Wstat: 0 Tests: 10 Failed: 3)
>>>>     Failed tests:  3, 6, 9
>>>> t\modperl\merge3.t                    (Wstat: 0 Tests: 10 Failed: 3)
>>>>     Failed tests:  3, 6, 9
>>>> t\modules\cgi.t                       (Wstat: 0 Tests: 5 Failed: 5)
>>>>     Failed tests:  1-5
>>>> t\modules\cgi2.t                      (Wstat: 0 Tests: 5 Failed: 5)
>>>>     Failed tests:  1-5
>>>> t\modules\cgipost.t                   (Wstat: 0 Tests: 6 Failed: 5)
>>>>     Failed tests:  2-6
>>>> t\modules\cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 5)
>>>>     Failed tests:  2-6
>>>> t\modules\cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 2)
>>>> [with LWP only]
>>>>     Failed tests:  1-2
>>>> t\modules\cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 2)
>>>> [with LWP only]
>>>>     Failed tests:  1-2
>>>> t\protocol\echo_block.t               (Wstat: 0 Tests: 3 Failed: 2)
>>>> [new failure for 2.4.x]
>>>>     Failed tests:  2-3
>>>> t\protocol\echo_nonblock.t            (Wstat: 0 Tests: 3 Failed: 1)
>>>> [new failure for 2.4.x]
>>>>     Failed test:  2
>>>> t\protocol\echo_timeout.t             (Wstat: 0 Tests: 5 Failed: 4)
>>>> [new failure for 2.4.x]
>>>>     Failed tests:  2-5
>>>> t\protocol\pseudo_http.t              (Wstat: 0 Tests: 13 Failed: 9)
>>>>    [new failure for 2.4.x]
>>>>     Failed tests:  3-8, 11-13
>>>> Files=3D252, Tests=3D2938, 848 wallclock secs ( 2.26 usr +  0.36 sys =
=3D  2.62
>>>> CPU)
>>>>
>>>> The ones marked 'new failure for 2.4.x' fail with 2.4.x but not with
>>>> 2.2.x so they are particularly worrying for 2.4.x support, but note
>>>> also that *none* of the above tests fail with 2.2.x when using trunk
>>>> (or mod_perl-2.08), which is also quite worrying.
>>>>
>>>> What is the current state of play on *nix? Which tests, if any, fail
>>>> using:
>>>
>>>
>>>
>>> Hi,
>>>
>>> I've had finally some time to do the tests. It's run on Fedora 20,
>>> httpd-2.4.9 and httpd-2.2.23. See below.
>>>
>>>> (1) httpd24threading + httpd-2.4.x
>>>
>>>
>>>
>>> t/compat/conn_rec.t                   (Wstat: 0 Tests: 2 Failed: 0)
>>>
>>>    Parse errors: Bad plan.  You planned 4 tests but ran 2.
>>>
>>> ^ This is expected problem for now. It's caused by renamed "remote_ip"
>>> and
>>> "remote_addr" in httpd-2.4. I was not able to put proper version check =
in
>>> this test (probably my lack of Perl knowledge).
>>>
>>> t/modules/cgi.t                       (Wstat: 0 Tests: 5 Failed: 2)
>>>    Failed tests:  2, 5
>>> t/modules/cgi2.t                      (Wstat: 0 Tests: 5 Failed: 1)
>>>    Failed test:  3
>>> t/modules/cgipost.t                   (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  1
>>> t/modules/cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  2
>>>
>>> ^ All these are caused by r1491887 -
>>> /perl/modperl/trunk/t/modperl/local_env.t. Should we revert this commit=
?
>>>
>>>> (2) httpd24threading + httpd-2.2.x
>>>
>>>
>>>
>>> t/api/server_const.t                  (Wstat: 0 Tests: 6 Failed: 2)
>>>    Failed tests:  5-6
>>> t/modperl/setupenv2.t                 (Wstat: 0 Tests: 23 Failed: 7)
>>>    Failed tests:  17-23
>>> t/modules/cgi.t                       (Wstat: 0 Tests: 5 Failed: 2)
>>>    Failed tests:  2, 5
>>> t/modules/cgi2.t                      (Wstat: 0 Tests: 5 Failed: 1)
>>>    Failed test:  3
>>> t/modules/cgipost.t                   (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  1
>>> t/modules/cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  2
>>>
>>> CGI tests fails for the same reason as in the previous case. Other test=
s
>>> fail *also* for trunk + httpd-2.2.x (see below).
>>>
>>>
>>>> (3) trunk (or mod_perl-2.08) + httpd 2.2.x
>>>
>>>
>>>
>>> trunk + httpd-2.2.23:
>>>
>>> t/api/server_const.t                  (Wstat: 0 Tests: 6 Failed: 2)
>>>    Failed tests:  5-6
>>> t/modperl/setupenv2.t                 (Wstat: 0 Tests: 23 Failed: 7)
>>>    Failed tests:  17-23
>>> t/modules/cgi.t                       (Wstat: 0 Tests: 5 Failed: 2)
>>>    Failed tests:  2, 5
>>> t/modules/cgi2.t                      (Wstat: 0 Tests: 5 Failed: 1)
>>>    Failed test:  3
>>> t/modules/cgipost.t                   (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 1)
>>>    Failed test:  4
>>> t/modules/cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  1
>>> t/modules/cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 1)
>>>    Failed test:  2
>>>
>>> Same as httpd-2.2.23 + httpd24threading branch.
>>>
>>>
>>>> ?
>>>>
>>>> If you have failures in (1) that aren't in (2), or failures in either
>>>> that aren't in (3) then we need eyes on them to try to get them fixed.
>>>> Perhaps *nix people could focus on failures that are common between
>>>> *nix and Windows, and I'll focus on Windows failures that aren't seen
>>>> on *nix?
>>>
>>>
>>>
>>>  From the tests above it looks to me that tests failing for
>>> httpd24threading
>>> branch are not httpd-2.4.x related on Linux. The same tests failing wit=
h
>>> httpd-2.2.x and trunk fail also with httpd-2.4.x and httpd24therading
>>> branch.
>>>
>>> I think from my point of view on Linux, it should be possible to merge
>>> httpd24threading branch with trunk without introducing any regression
>>> which
>>> would be visible on our test-suite.
>>>
>>>
>>>> If we can't fix things any time soon then perhaps we should take a
>>>> vote on whether to release as-is, with documentation updated to note
>>>> the currently known problems?
>>>
>>>
>>>
>>> I'm not able to help with Windows specific bugs because of lack of
>>> knowledge
>>> and time for that. But if we fix the bugs mentioned above, maybe we cou=
ld
>>> release some alpha mod_perl with initial httpd-2.4 support and see what
>>> happens.
>>>
>>> I have no knowledge to evaluate how hard it will be to fix mod_perl wit=
h
>>> httpd-2.4 on Windows. If I remember well, even httpd-2.4.x itself had f=
ew
>>> 2.4.x releases with some Windows related bugs...
>>>
>>>
>>>> I am keen to see a mod_perl-2.09 with httpd-2.4.x support, but not if
>>>> it's in a buggy state (especially on *nix) that will just generate a
>>>> ton of bug reports and disappointed users.
>>>
>>>
>>>
>>> If the tests are passing and we don't have more people testing trunk, w=
e
>>> will have to consider releasing something to get more testers and more
>>> attention.
>>>
>>> We have httpd24threading branch in current Fedora for some time and the=
re
>>> are no bug reports yet. Some people within Red Hat are using mod_perl
>>> with
>>> httpd-2.4 too.
>>>
>>
>> Thanks for testing, and sorry I've taken so long to get back.
>>
>> So it looks like you're happy on Linux, except for one known failure
>> (compat/conn_rec.t) and a bunch of failures caused by r1491887.
>>
>> I will try testing with that change reverted and see what results I
>> get. Presumably it will fix the same things that it fixes for you; I'm
>> curious to see whether it also fixes anything else.
>>
>> Aside from that, we have two sets of failures on Windows only:
>>
>> - modperl/local_env.t & merge*.t failing with either httpd-2.2 or 2.4,
>> but they work with trunk (on httpd-2.2, obviously)
>>
>> - protocol/echo_block.t, echo_nonblock.t, echo_timeout.t &
>> pseudo_httpd.t failing with httpd-2.4 only
>>
>> I've looked at all of these before and made little headway. I will
>> look again while I play with reverting r1491887, but otherwise I fear
>> we're going to have to release 2.0.9 with these known Windows failures
>> so that it doesn't hold up an otherwise good Linux release any longer.
>>
>> So I will probably start merging httpd24threading back to trunk soon
>> if there are no objections...
>
>
> That sounds great :). From my point of view it's good plan. I would vote =
for
> releasing some alpha version so we could get some more testing like the o=
ne
> provided by Alexander earlier this week.
>
> For me the Linux version is working properly on Fedora, but on different
> distributions and systems we could find out more bugs like that one, but
> without anyone else testing httpd24threading branch it will be quite hard=
 to
> move with httpd-2.4 support.
>
> Regards,
> Jan Kaluza
>

With r1491887 reverted I now have all tests passing when using
httpd-2.2 (yay! that makes me much happier), and with httpd-2.4 I only
have the expected failure plus one of the sets of Windows-specific
failures (protocol/echo_block.t, echo_nonblock.t, echo_timeout.t &
pseudo_httpd.t).

That would be acceptable for release (I really wasn't happy with a new
release breaking 2.2 support...) so I think we'll have to revert
r1491887 for now, and then I'll get merging stuff back to trunk after
looking at that remaining group of failures again.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org