Hi!
It looks like the situation with the tests significantly improved
(again, thanks a lot for everybody who took part!), so I plan to package
5.4 beta tomorrow. If you have any fixes that must be in the beta
(please test! ;), please do it in the next 12 hours or after the beta is
tagged.
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi:
SessionHandler is not stable now, and remain some bugs need to be
fixed(one open bug #55690, and test failed)
and arpad can not be connected now, so you may need to double
check with him when you start packaging.
thanks
2011/9/14 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
It looks like the situation with the tests significantly improved (again,
thanks a lot for everybody who took part!), so I plan to package 5.4 beta
tomorrow. If you have any fixes that must be in the beta (please test! ;),
please do it in the next 12 hours or after the beta is tagged.Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Laruence Xinchen Hui
http://www.laruence.com/
SessionHandler is not stable now, and remain some bugs need to be
fixed(one open bug #55690, and test failed)
It's a beta release. Bugs may occur (that's why we have betas!).
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi:
Sure, I just said need to be double check. :P
thanks
2011/9/14 Derick Rethans derick@php.net:
SessionHandler is not stable now, and remain some bugs need to be
fixed(one open bug #55690, and test failed)It's a beta release. Bugs may occur (that's why we have betas!).
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
Laruence Xinchen Hui
http://www.laruence.com/
SessionHandler is not stable now, and remain some bugs need to be
fixed(one open bug #55690, and test failed)It's a beta release. Bugs may occur (that's why we have betas!).
it's true, but it's neither a snapshot.
I would expect a beta to be more stable than a random snapshot, so it
would be useful, if the we wouldn't add untested/broken modifications
just before the beta release.
I'm not directly referring to the sessionhandler or #55690 particular,
but the tendency that everybody wants to push his changes just days
before the beta1.
they can be added with the next beta, so no hurry, I would appreciate
fewer but more stable features than one with more but unstable.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Stas Malyshev wrote:
If you have any fixes that must be in the beta
Some of my fixes are still awaiting review :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
hi!
I would rather say try to avoid committing huge changes before the
beta1 is out. The current tree builds and runs more or less good
(there are still some bugs around but it is acceptable for beta). It
would be bad to have last minute breakages only because of one or two
commits.
Cheers,
Hi!
It looks like the situation with the tests significantly improved (again,
thanks a lot for everybody who took part!), so I plan to package 5.4 beta
tomorrow. If you have any fixes that must be in the beta (please test! ;),
please do it in the next 12 hours or after the beta is tagged.Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
It looks like the situation with the tests significantly improved (again,
thanks a lot for everybody who took part!), so I plan to package 5.4 beta
tomorrow. If you have any fixes that must be in the beta (please test! ;),
please do it in the next 12 hours or after the beta is tagged.
Could you look at the intl tests?
I have similar failures the the gcov, plus couple of more I sent you
the other day.
-Hannes
please post errors&co to the list, ccing the maintainers too. It is
then easier to be in sync.
About intl, it seems that many tests are ICU version specific
(regarding unicode and formatting rules correctness). Maybe we need to
add a couple of skipif and use the latest ICU version only as base
(where the unicode&co issues are fixed).
On Wed, Sep 14, 2011 at 10:25 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Hi!
It looks like the situation with the tests significantly improved (again,
thanks a lot for everybody who took part!), so I plan to package 5.4 beta
tomorrow. If you have any fixes that must be in the beta (please test! ;),
please do it in the next 12 hours or after the beta is tagged.Could you look at the intl tests?
I have similar failures the the gcov, plus couple of more I sent you
the other day.-Hannes
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
please post errors&co to the list, ccing the maintainers too. It is
then easier to be in sync.
I really do not like it when you assume everyone else are idiots.
I ofcourse already sent it, in fact, it was in a reply about intl
tests failure thread that you yourself created.
-Hannes
Hi!
Could you look at the intl tests?
I have similar failures the the gcov, plus couple of more I sent you
the other day.
Yes, I will. From casual look it seems like they are caused by variation
between ICU versions, I'll look into how to make tests better - though
for some tests it may be hard to do...
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Could you look at the intl tests?
I have similar failures the the gcov, plus couple of more I sent you
the other day.Yes, I will. From casual look it seems like they are caused by variation
between ICU versions, I'll look into how to make tests better - though for
some tests it may be hard to do...
We do need tests per version. The EXPECTF-<configuration/platform>
becomes more and more necessary :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
We do need tests per version. The EXPECTF-<configuration/platform>
becomes more and more necessary :)
The problem is data may vary by CLDR version, etc. and keeping pace with
all variants on all platforms, etc. will be a nightmare.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
The problem is data may vary by CLDR version, etc. and keeping pace with all
variants on all platforms, etc. will be a nightmare.
To have a couple of versions, say x.y, x.y+1 sounds reasonable and possible.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The problem is data may vary by CLDR version, etc. and keeping pace with all
variants on all platforms, etc. will be a nightmare.To have a couple of versions, say x.y, x.y+1 sounds reasonable and possible.
Its not our responsibility to test the 3rd party library data, thats
for intl to test.
Just like its not our responsibility to test flex or OS network error messages.
We need to test that we understand the data and work with it properly.
My test failure seem to be both caused by data difference, but also
float precision and timezone issues, and thats within our domain to
ensure is working fine.
-Hannes
On Fri, Sep 16, 2011 at 10:10 AM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
The problem is data may vary by CLDR version, etc. and keeping pace with all
variants on all platforms, etc. will be a nightmare.To have a couple of versions, say x.y, x.y+1 sounds reasonable and possible.
Its not our responsibility to test the 3rd party library data, thats
for intl to test.
It is not about validating the correctness of ICU itself but our
binding or APIs usage. And to do that we have to deal with the ICU
results.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hannes Magnusson wrote:
My test failure seem to be both caused by data difference, but also
float precision and timezone issues, and thats within our domain to
ensure is working fine.
The remaining interbase/firebird errors are similar niggles ... but I'm not sure
just how one would know that the error was actually the same data just viewed
slightly differently? Float with the E or fully expanded is one which pops up
often?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php