> -----Original Message----- > From: Derick Rethans [mailto:[EMAIL PROTECTED]] > Sent: 15 January 2003 15:17 > To: [EMAIL PROTECTED] > Cc: PHP Quality Assurance Team Mailing List; PHP Developers > Mailing List > Subject: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: > sprintf) > > > On 15 Jan 2003 [EMAIL PROTECTED] wrote: > > > Why has this bug been marked as Bogus when it's a > Duplicate? It seems > > to be increasingly common for this to happen -- when did it become > > standard policy to set duplicate report to Bogus? > > Two exactly the same bugs were posted one minute after eachother from > persons on the same domain.
(Grits teeth) But it's still a duplicate report! > It was in this case. > > > And even if it is policy to set duplicate report to Bogus, > that policy > > should be prominently documented, so that people don't get in a huff > > about bugs being dismissed as not a bug when their > duplicate report is > > set to Bogus (which has happened more than once already!). > > People who dont understand the implicit meaning of the statii > shouldn't > touch the reports in the bug system. I'll write them down again: I'm not talking about touching them in the bug system, I'm talking about understanding them as a bog standard user. > > bogus: submitted twice after each other, or by the same person on the > same topic; it's not a bug, but a support question. The reason > should always be noted in the comments That's very confusing - there's really two different stauses in that definition, which I think is the crux of the problem. The first definition really needs a new status such as "Repeat", which is otherwise treated like Bogus. But this definition is interesting, because I think some responders are not respecting the "by the same person" part. > dupli: almost the same bug, both bugs are found 'duplicate' > later on and > have both useful information Yes, fair enough. I just get the feeling that, lately, the balance has tipped too far towards labelling repeat reports Bogus -- personally, I think responders should be a little less Bogus-happy, and err on the side of Duplicatifying if there's any doubt in the matter. Also, when marking a "repeat" as Bogus, not calling it a duplicate in the explanation would be useful -- saying something more like "repeat of #xxx" or "Identical to #xxx" would be better. > verif: a member of the QA has verified the bug to be a real one > analy: the cause of the bug is known, or a solution is known > for it but > not yet implemented > assig: don't touch this one, somebody is working on this. > open: just submitted, or nobody knows what to do with it (after > feedback) > feedb: Waiting for more feedback from the user > suspe: at some point in the future we'll look at it again, > currently we > are waiting on an external thing to be fixed first > close: the bug has been solved (fixed in cvs) > wontf: we are not going to fix this issue because .... > criti: critical bug, should be fixed ASAP > no fe: No feedback from the user was added since we asked it > two weeks > ago H'mmm, interesting -- I don't think I've ever seen that list before -- certainly not linked from anywhere obvious such as http://bugs.php.net/, or http://bugs.php.net/search.php. Perhaps a "what happens to bug reports" sort of link would be useful on the bugs front page, to complement "How to report a bug"? Cheers! Mike --------------------------------------------------------------------- Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
