Hy,
And exact here is my personal problem ;-)
I am the main author and only person who codes all the I18N classes.
There is no other contributor. So I must ask Zend to review my code.
There may be no other core contributors for the i18n classes, but there
are dozens of contributors to the framework. I monitor the i18n list as
I'm sure many others do. if you need a reviewer, I'm sure any one of us
would be happy to look at your code.
Would be great...
As always I am of course speaking out loud what others dont want to say
because they are to shy ;-)
And what about fixes which do not include unit tests ?
For example...
I am not able to write tests for issues which are related to 64bit
machines only
or for race conditions.
Then how can you be sure that the bug has been fixed? Bug fixing is where
unit tests truly shine: before you fix a bug, you write a test that shows
the bug exists. Then you fix the bug. In this way, you can be assured
that you will never re-introduce the bug because there will always be a
test for it.
Speaking of the two mentioned cases:
There was a bug within the gettext adapter which only occur on big endian
encoding with particular 64bit machines.
On other 64bit machines the problem did not show. The reason is a bug within
php itself.
How should I code a test, when I am not able to reproduce it ?
And in my opinion the already written tests were broken within these
machines.
But the people who committed the bugs were not able to run unit tests on
their machines.
And I know that the bug was fixed because I gave the changed lines to the
one who had the bug and he said it worked.
The second bug I mentioned could not be reproduced...
Wether by me nor by the one who wrote us the bug.
I only added two exceptions for handling such impossible conditions.
If this conditions arise someone has changed the locale source files and
this is something I am not able to write a test for.
Speaking of normal bugs, I am of course always writing the unit tests...
If you look at the testbed for Zend_Date you will see that it is the biggest
of the whole framework.
This is normal coding process...
No I can not...
For example Zend_Date....
I've integrated new features (array access).
But when there is a new bug I have to integrate it in
trunk (where the new feature resists) and in maintenance.
Otherwise the maintenance branch would also have the
new feature integrated which is not allowed.
You should simply checkout two working copies, one from the branch, and
one from the trunk. This is how I've handled maintenance branches for
years.
That's exactly what I expected and asked for, but noone wanted to answer
this definitly.
Review:
--------
So I need review and integration of the following trunk changes:
5636
5720
5721
I would have to integrate them into the next tag release.
All other changes could be reviewed
5693
5628
5618
5586 - 5613
and are for 1.1.0
Greetings
Thomas
I18N Team Leader
