Re: Bug Database improvement

Marko Karppinen wrote: > Hi! > As you all know, most of the traffic on this list is bug system chatter. > While often interesting, especially bugs in the feedback loop seem to > generate some excess messages to the list. > How about this: assigning a bug to somebody would stop the bug system > correspondence to the php-dev list. The initial bug report message would be > sent to the list, as would the final closure message. > If the assigned-field was extended to allow for multiple people working on a > single bug, then this might actually work. > Any opinions? "With enough eyes, all bugs are shallow"-- paraphrase of Linus Torvalds I don't think that removing the chat is a good idea. The chat itself is a major part of solving the bugs, of discovering the root cause. I'll give you an example: 1. Function xxx_yyy is misbehaving, initial report is unclear, so person "a" familiar with the functions asks for more details. 2. User provides more feedback on the bug, which seems to be related to compile time option on the function. Bug is then assigned to someone familiar with compile time options.... *BUT*.... 3. Compile time option is unrelated. Bug still persists. Somebody on the list (person "b") notices it's similar to a C library error on Solaris that they've fought with before, in a totally unrelated funtion. "b" posts some more info about possible fixes. 4. User updates library, now the error only manifests when using a different function, and the code has now broken on user's FreeBSD box... person "c" has seen this on FreeBSD, and sends info to "a", "b", and the user.... 5. User has now fixed bug, based on three different bug fixers and the user's own efforts. If we only had those assigned to a bug getting updates, the other helping "eyes" would have never seen this info. How often does this kind of thing happen? Well, for instance, there is a LDAP/Oracle bug that manifests itself dependant on ldap/oracle compile time options. To reasonably track this down, whomever was assigned the bug might need to know the compile options, Oracle, OpenLdap, Netscape LDAP, etc. etc... or each person assigned to a bug would need a linux machine, a freeBSD machine, a solaris box, an NT box, and absolutely insane amounts of other software to replicate the problem... and even then, their fix might only pertain to one library on one OS, leaving the other OS's potentially broken, unless all php programmers were gods of all OS's, databases, libraries, etc. etc. To summarize, taking eyeballs away from debugging is not good. If individuals only want to see specific bug types, they can filter for them. If you only want to see opened and closed bugs, you can filter for "Updated" and stuff those messages into a bit-bucket. -Bop -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary.