#44040 [NEW]: dealing with error-reports is unacceptable
[email protected] ("spam2 at rhsoft dot net")
| Newsgroups | php.webmaster |
|---|---|
| Message-ID | <[email protected]> |
From: spam2 at rhsoft dot net Operating system: PHP version: Irrelevant PHP Bug Type: Website problem Bug description: dealing with error-reports is unacceptable Description: ------------ http://bugs.php.net/?id=42262 What crazy person implements "You can not comment bogus reports or change their status." in the system from the time any crazy guy believes to set this status? Do you think its fun for me testing snaphsots and writing bugreports and see ignoring them and make me unable to comment this - I make this work for helping you to do yours easier and getting updates containing less bugs/problems. Damend do not set to "bogus" before inital-reporter can say anything to an answer getting months after report or fix this idiotic system so the reporter can make clear his point of view maybe resulting in re-opening! _______________ I have no time to check this now, but i will see the next days running a snapshot build The NEWS-File from source is not useful because there are no dates It is simple NOT ACCEPTABLE if the function will not exist any longer because the truth is that it is disabled in php6 so the function have simply to return false. Where is a reason to break this? If the error-message is away th bureport has to get status "fixed", if it still exists the NEWS-File and actual result are not the same, status "bogus" this time a can not see! ______________ I have a problem with the way php is developed and bugreports are handled. Everytime will anyone tell me "bogus" and after long discussions the solution is pointly the one i requestet from the begin. The game in this bugreport setting to bogus/open and bogus again some months after initial report is a bad joke also as nonone makes a clear statement - as bugreporter it is not my job to read every mailing-list and archive - HERE is the point for clear statements for THIS report ___________ Sample: http://bugs.php.net/bug.php?id=42077 See comment 2/3 from jani The second answer was after a private mail from me to let me know if some people ace total crazy http://bugs.php.net/bug.php?id=42836 Instead checking what goes wrong comes a fucking comment Damned it is a problem with php6 if you randomly get openbasedir-errors showing that settings from another vhost will be mixed and with the same configurations php5 had never a problem in any way - you can reload the page one, two, three times and the error goes away and another virtual host has the same with settings from the last visited. If you handle bug-reports in this way finally many people will not test snapshots and writes reports in future - is this what you want? -- Edit bug report at http://bugs.php.net/?id=44040&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44040&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44040&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44040&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44040&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44040&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44040&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44040&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=44040&r=needscript Try newer version: http://bugs.php.net/fix.php?id=44040&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44040&r=support Expected behavior: http://bugs.php.net/fix.php?id=44040&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44040&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44040&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44040&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44040&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44040&r=dst IIS Stability: http://bugs.php.net/fix.php?id=44040&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44040&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44040&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44040&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=44040&r=mysqlcfg