Hi Thomas, You obviously can't do what you can't do. If you can't reproduce but had someone else validated that the fix is good then that's in the spirit of what we wrote. In most cases you should still be able to write a unit test that would fail on his system (otherwise how did he verify that it was fixed). Note: You did ask another person to verify your patch which is in the spirit of what we wrote.
It's important to understand that these guidelines are trying to help everyone stick to a good high-quality process. We will have to tweak as we implement them in real-life. I think most would agree though that if we can follow this process we will end up a higher-quality project than most others. Just the notion of asking people to get peer review is something which is not implemented explicitly in most other projects. With the Zend Framework we don't only want to deliver best practices with the framework itself but also lead by example in how we develop, test and document. Andi > -----Original Message----- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 2:34 PM > To: Willie Alberty; Zend Framework > Subject: Re: [fw-general] Re: Lifecycle Handling > > 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 > >
