Towards Mozilla 1.0
Tuesday June 26th, 2001
Gervase Markham recently posted his feelings on what a 1.0 release of Mozilla would be. Gerv has sent us the follow-up to that posting, including much of the feedback he received. To read it, click the full article link. Once you have read through it, we welcome you to post your feelings on what you think a 1.0 release would have. [As Gerv says, please don't post your favorite list of bugs, only the criteria for choosing what bugs to fix.]
#216 numbers look very wrong to me
Friday June 29th, 2001 8:28 PM
You are replying to this message
Can you please post a query here which shows all of the (450 or so) patches which have not been checked in yet and were submitted by people not at Netscape. I'm fairly comfortable with queries in Bugzilla and no matter how many times I try I can't come anywhere near the 450 hits result of your query. I've actually been working on tracking this kind of information since early in the year and my numbers don't look anything like yours. My numbers generally show that there are about 3 or 4 patches which have not received the attention that they deserve. If you found 450 then you're in possesion of a goldmine that I'd like to get my hands on.
As far as I know you cannot query for attachement <data|description> changed by sub-string or regexp (for example @netscape.com or not @netscape.com). If you have found a way to do this please share it with me. It seems to me that the boolean tool only allows you to query for exact matches on "changed by".
And how did you determine if the patch was attached before the bug was reopened? Many of the open bugs with patches were fixed by those patches and then reopened and the patches are no longer relevant.
Also, If you got that far can you tell me how you determined which patches were not in the r= or sr= state of being reviewed. I worked really hard to try to develop a query that would show bugs which have comments of one thing (ex. [sr]=?|r=[a-z]) but not comments of another (ex. r=[a-z]|sr=[a-z]). The problem there is you cannot query for bugs where _no_ comment contains some string, you can only query for bugs where _one_ comment does not contain some string. So if you were to query for all bugs that had one comment that contains r= and one comment that does not contain sr= you effectively end up with the same first batch of bugs that contain r= since it only takes one comment not containing sr= to result in a hit (most bugs have one comment that doesn't contain just about every string).
And then there's the whole problem of determining if the attachment is even a patch. You cannot rely on "Attachment is patch equal to 1" since there was a bug in Bugzilla which treated all attachments as patches for a period of time. And you cannot rely on the patch keyword since it is applied so randomly (along with the review and approval keywords). I did find a couple of queries which could narrow it down quite a bit but there were still false positives. (attachment data contains certain strings like @@@ and ++, etc.)
Then there's the whole problem of patches which simply didn't pass review or were rejected as incorrect immediately (and even by their author in some cases).
Like I said, if you have come up with methods of query which work around or solve these issues please let me know. I would very much like to be able to better track this info in Bugzilla. (It should all get better when myk's attachment manager addition to Bugzilla lands but that won't help us with the existing attachments).