Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54815
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sury.org designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20110823023321.GA28179@panix.com>
References: <CALjhHG9BiXU=NzhAYcNT6aetjwvhkyTRwR=pOTJs8AuzmG2B8Q@mail.gmail.com>
 <CAEZPtU6pLF+UVa=LHWVcjpQZHv7CLw9br1_2nWkrrHS4jPXK1A@mail.gmail.com>
 <4E52D8DC.6000007@sugarcrm.com> <20110823023321.GA28179@panix.com>
Date: Tue, 23 Aug 2011 09:09:37 +0200
Message-ID: <CALjhHG-=pmmaUu9g3ek4DCX4eBmfzU45bbiwsOTfc8Kc_J6Bvg@mail.gmail.com>
To: Daniel Convissor <danielc@analysisandsolutions.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.3.6-13 -> 5.3.7-1 test result diff
From: ondrej@sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=)

Hi all,

On Tue, Aug 23, 2011 at 04:33, Daniel Convissor
<danielc@analysisandsolutions.com> wrote:
> Hi Stas:
>
> On Mon, Aug 22, 2011 at 03:31:56PM -0700, Stas Malyshev wrote:
>>
>> We still have tons of failures in DateTime IIRC and that's because
>> of the buggy three-letter timezones.
>
> There are bugs with both type 1 (regularly created datetimes) and type 2
> (datetimes created using three letter timezones) timezone objects when
> it comes to the daylight/standard time transition. =C2=A0I've composed a
> first draft of an RFC on how PHP should behave regarding these
> transitions and am refining it with Derick. =C2=A0I hope it will be finis=
hed
> soon. =C2=A0Once that's done, the code can be fixed to match the expected
> behavior.
>
>
>> not fixed - would be great if we could have it for 5.4 release.
>> Derick?
>
> Yes, it would be great for this to be in 5.4.

I probably don't know enough about procedures here. But if you know
that the tests are failing, you should move them to XFAIL category,
don't you? So if there is a test which falls into the FAILED, you can stop
the build and investigate what went wrong.

This will also allow you to do automated tests on nightly builds and
make the tests mandatory before the release by enforcing the policy
by some release scripts. Or make the tests mandatory on every build
with option to turn them (selectively) off.

I will also try to automate this process in the Debian packages (saving
list of failed tests somewhere and comparing them to the results of the
build). But that doesn't mean the results will be same as vanilla PHP
(embedded vs shared libraries, some Debian specific patches, etc.)
and same on different systems with different libraries.

O.
--=20
=EF=BB=BFOnd=C5=99ej Sur=C3=BD <ondrej@sury.org>