Re: Work on the Bug Reporting System (00/08/04)

> ZG>> Not Reproduceable > ZG>> * If the bug cannot be reproduced in a current release, end the bug life > ZG>> cycle here. > ZG>> Note the full details of platform and version tested with. > > Wrong here. Bug can be not reproduceable on your config but reproduceable > on user's. Anything could be the cause - different version of system > library, different compiler, phase of moon, etc. True. If the bug is not reproduceable by the bug hunter in a current release, then contact the user to confirm that the bug also disappears for them when they install a new release. If this is not the case, then what? Gather more information? Ask for access to user system? > ZG>> Not Analyzable > ZG>> * If no cause can be determined, then other developers should be contacted. > ZG>> * If no cause can be determined after rigorous analysis, then the bug cycle > ZG>> should end here. > > Erm? If you have confirmed bug that you don't know why it happens, you > don't end with it, you spend sleepless nights until you find what's the > cause. In other words, bug sits and waits until somebody reaches the > enlightment and says - "wow! that comma in line 42 of foo.c is the > cause!". ok > ZG>> Not Fixable > ZG>> * After analysis, the bug may prove to be unfixable. If this is the case, > ZG>> then close end the life cycle here. > > If it's unfixable, we call it "feature" :) <laugh> I don't see too many bugs that would end up here - actually, come to think of it, this probably only apply to bugs that are caused by factors that we have no control over - like features of Win32. In which case, it would not be a PHP bug... > ZG>> Regression Test > ZG>> * Once the fix is in place, a regression test should be in place to catch > ZG>> re-occurences of the bug in the future. > > Some bugs are rather hard to make testable (like: "PHP crashes when I > close connection to MySQL server and my reverse DNS is down"). Then this should be marked as optional. Thanks for the feedback! Zak