The NSS team has an ongoing problem with "lost patches". While a patch is awaiting review, it is easy to find on the "my requests" page. But once it is reviewed (either approved or denied), it drops off the radar, and is very difficult to find again. So, a developer creates a patch, requests review, and days/weeks/months later, it gets reviewed. But then it disappears. Consequently, reviewed patches often are forgotten. We need a way to find (open bugs with) patches that have been reviewed, but that were not marked obsolete. Those are potential "lost patches". Presently we can search for bugs based on this patch information: Attachment description Attachment data Attachment filename Attachment mime type Attachment is patch Attachment is obsolete Attachment is private review status (and super-review status) are not among the searchable criteria. Please add those searchable criteria.

(In reply to comment #0) > review status (and super-review status) are not among the searchable > criteria. Please add those searchable criteria. > Wrong! I do it every day to get the list of patches ready for checkin, even on b.m.o. You have to use boolean searches on query.cgi. Or you can even use the hidden 'status' field in request.cgi. This hidden field will be visible thanks to bug 329649; but that's another bug.

In comment 0, I listed the searchable items in boolean searches, as shown on b.m.o. If you claim that it is possible to search for bugs with reviewed patches, then please cite the syntax for such a search, and show how that is selected using the form on https://bugzilla.mozilla.org/query.cgi

Our policy is to not answer support questions in b.m.o. But here is the regexp you are looking for anyway: https://bugzilla.mozilla.org/buglist.cgi?product=NSS&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=regexp&value0-0-0=%28super%29%3Freview%28%5C%2B%7C-%29&field0-1-0=attachments.isobsolete&type0-1-0=notequals&value0-1-0=1

The relevant part of your answer seems to be this: &field0-0-0=flagtypes.name &type0-0-0=regexp &value0-0-0=%28super%29%3Freview%28%5C%2B%7C-%29 &field0-1-0=attachments.isobsolete &type0-1-0=notequals &value0-1-0=1 which seems to match this boolean expression (using the query form) Flag contains regexp (super)?review(\+|-) and Attachment is obsolete is not equal to 1 However, this search expression does not produce the requested result. Among the bugs returned by this search is bug 241081 That bug has one patch that is reviewed, and is marked obsolete. It has another patch tht is not reviewed, and is not marked obsolete. It does not match the desired search criteria. That is, it does not contain any patch that is both reviewed AND non-obsolete.

The final issue seems to be that boolean search expressions don't all apply to the same attachment. I'll file a separate bug about this one.

right. My saved searches usually do not use the AND relation as I don't care about whether they are obsolete or not. I now realize that the AND relation only looks for *one* patch which is reviewed and *one* attachment which is not obsolete, but doesn't make sure that we are talking about the same attachment. I was pretty sure we fixed this issue... but it is still open, see bug 180812. I will motivate joel to fix it. :) About the fact that you cannot look for attachments being reviewed, this bug is WORKSFORME, per my comment 1 and 3. About the fact that the AND relation doesn't work as expected (actually it does, as we never said it had to look at the same attachment for both the flag and the "is obsolete" bit), that's a dupe of bug 180812. So I will mark this bug as such. And *please*, do not reopen it again. :) *** This bug has been marked as a duplicate of 180812 *** *** This bug has been marked as a duplicate of 180812 ***

How did you change the resolution from WORKSFORME to DUPLICATE without reopening the bug in between?

(In reply to comment #7) > How did you change the resolution from WORKSFORME to DUPLICATE without > reopening the bug in between? > I changed "several bugs at once", which allows us to change the resolution without reopening bugs.

Frederic, Your bad attitude has kept this bug from getting fixed for 4 years now. You're disqualified from the bug bounty I have offered for a fix.