I vote for a much similar query page addition for this new average bugzilla filers myself because the current query interface really is too complex and advanced for the average user. People on the project probably dont' have a problem with this, but newer people find this really arcaic. I've seen way better search implementations than this and find more of what I've tried to search for. Right now, as it is, I file more bugs under bustage between builds the same day. So pulling up an already-filed-today should allow an easy way to change to 2 or 3 days or 1 week. This is not that easy to duplicate from from scratch into a search that works.
-Dman84 Simon P. Lucy wrote: > At 16:10 21/02/2001 +0100, Andreas Franke wrote: > >> > I've voted for it. >> >> Thanks. >> >> > I have some reservations about using substrings when >> > looking for bugs, unless the user uses the same terms they are >> unlikely to >> > hit on substrings >> >> Sorry, I don't understand. If you search for substrings, you only get >> _more_ >> hits than a search for "all words" would give you. E.g. if you search for >> "wheel mouse", you get hits for "wheel mouse", "wheelmouse" and >> "mousewheel". >> What's the problem with this? Too many hits? If that's the problem you >> can use >> "#mouse #wheel" to search for these _words_. Ok, that's not >> documented, maybe >> I should do it? > > > Oh you should definitely document the '#' as it isn't :-). Substrings > are bad if people use phrases and those phrases are searched for because > its unlikely that people will use the same phraseology (I think this is > the main reason for Bugzilla general searches failing for users). > That's how the current Bugzilla search works, if yours doesn't then its > an even greater reason for using it. > > >> Replacing "substring" with "allwords" everywhere would be easy, but >> I'm not >> sure if that's what you want. Let me quote from bug 65190: >> >> >Both "(case-insensitive) substring" and "all words" comparison types >> are not >> >optimal solutions if you want to query for several words: >> > >> >>> The problem with the Simple one ["(case-insensitive) substring"] >> >>> is that, if people put in a few words relevant to their bug, it's >> >>> reasonably unlikely that those words will appear in that exact order >> >>> in the summary. Could we do "all words" instead? >> >> >> >>i've never found "all words" to be useful, because it won't let you >> type >> >>"bookmarklet" and get hits for both "bookmarklet" and "bookmarklets". >> > >> >C.Begle's SimpleSearch >> <http://www.mozilla.org/quality/help/simplesearch.html> >> >solves this problem by generating boolean charts on the fly. >> >> > even if they use stems of words (itself not user friendly). >> >> That's true. Solution: For a lecture about information retrieval, I >> had to >> implement a "porter-stemmer", a program that computes stems automatically >> using the "Porter-Algorithm" - a standard procedure. Actually, I did not >> implement it but downloaded an implementation from the web. It's a C >> program, >> and it's very fast. As soon as someone ports the tool to perl (from >> javascript) and thus turns it into a server-side program, it should be >> easy to >> integrate this stemmer and do it automatically (at least on the default, >> non-Hackers page). > > > Yes if I remember rightly Porter works well with nouns, adverbs and > adjectives but less well with passively tensed verbs. Have you raised a > Help Wanted bug with the C source as an attachment? If you do that I > might even be moved myself to do it :-) > > >> > I find that using all words is easier for novices (and for >> > myself if truth be told). >> >> Maybe then you prefer a simple "all words in summary" form? That's a >> one-liner, well, almost. Would it be ok for you if there was an "all >> words in >> summary" quicksearch box on the bugzilla front page, with an "[Help]" >> link >> pointing to the QuickSearch page mainly as it is now (but noting the >> difference between the two)? > > > Hmmm, actually the summary field (if that's what you mean), is almost > useless for searching, other than maybe filtering by component if that > applies I tend to search the description field it generally repeats what > is in the summary anyway. > > >> > What I'd really like is a proper Search pane for >> > Bugzilla with the main elements of your quick search in it. >> >> Something like the "Medium Form" link at the bottom of the Quicksearch >> Page? >> Or something like >> http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4482 >> from bug 16775? > > > Perhaps something in between the two :-). But really your quicksearch > is fine together with some persistent switches for +DUP ALL/FIXED as > well as a component filter would suit me down to the ground. > > Oh there is my continual bugbear of american spelling :-), a transposer > that searched for s|z and l|ll would help a lot. > > Simon > > > >> Cheers, >> Andreas > > > =================================================== > If I'd known I would spend so much time sorting and rearranging boxes > I'd have paid more attention at kindergarten > > S.P. Lucy > > >
