Re: Is a new bug reporting system needed?

> On Mon, 3 Jul 2000 13:52:43 -0700, Chris Adams wrote: > > >> The biggest problem seems to be too many open bugs - as many people have > >> suggested, perhaps we should just focus on getting those cleared up. > > > >Definitely. I think one very simple but effective measure would be allowing > >the QA team to confirm bugs (perhaps with commentary). That'd allow the > >developers to fix confirmed problems before looking at what's left. > > Yes, excellent idea. If we have enough people, then we should be able > to find the right setup somewhere to confirm whether or not the bug can > be reproduced or not. Course, if we can't reproduce it, it could still > be a bug.... Exactly - the idea is that the QA team acts as a filter to save time for the developers. If a developer has two problems to fix, one of which has a vague description and one of which has a comment from QA along the lines of "Yeap, broke on $PHP_VERSION with $TEST_FILE here, too", they'll probably fix the confirmed one first. > >track it down exactly. It'd be handy if there was a place where QA people > >with spare time could see items which have been flagged as behaving > >suspiciously, see if they can make it break and then submit a well prepared > >bug report instead of the "$FEATURE fails weirdly" bug report that'd > >probably be filed otherwise. > > But, really, shouldn't you file a bug report? This is precisely the > situation we have to deal with, because a lot of the bugs in the > database fall into that category ("not sure what it is, but it don't > seem to work..."). Setting up a special process for this is > sidestepping the problem. In this case, I'd prefer to have something a little more solid than "under certain conditions I haven't identified DOS line termination will annoy the PHP parser". Otherwise, I have a strong feeling that the developer would create a file like this: <? echo <<<END foo END; ?> verify that it works with either flavor line termination and close the bug report. If nothing else, I was going to strip out the includes() & calls that wouldn't be available on someone else's system.