Summary: | Teach webkit-patch how to search bugzilla | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||||
Component: | New Bugs | Assignee: | Eric Seidel (no email) <eric> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | abarth, cjerdonek, commit-queue, eric, tony | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Other | ||||||||||
OS: | OS X 10.5 | ||||||||||
Attachments: |
|
Description
Eric Seidel (no email)
2010-12-03 15:53:34 PST
Created attachment 75567 [details]
Patch
This is a work-in-progress patch. Searching works, but is very slow. Also the code has some layering issues which I'd like to resolve before geting a real review. Just checkpointing my work in bugzilla. Created attachment 75587 [details]
Patch
I'm not sure the "bug-search" command is very useful. But this infrastructure will enable us to do other searching, like for bugs about flaky tests. :) Comment on attachment 75587 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=75587&action=review > WebKitTools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py:86 > + if result_count_parts[0] == "Zarro": > + return 0 Zarro! > WebKitTools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py:106 > + self._bugzilla.browser.select_form(predicate=self._is_xml_bugs_form) > + bugs_xml = self._bugzilla.browser.submit() :( Can we at least assert that self._bugzilla is in the proper state. > WebKitTools/Scripts/webkitpy/tool/commands/bugsearch.py:33 > + name = "bug-search" search-bugs maybe? > WebKitTools/Scripts/webkitpy/tool/commands/bugsearch.py:40 > + print "%5s %s" % (bug.id(), bug.title()) What happens when we get six digit buts? > WebKitTools/Scripts/webkitpy/tool/commands/bugsearch.py:42 > + print "No bugs found matching '%s'" % search_string zarro! Comment on attachment 75587 [details]
Patch
Going to land as-is. Happy to change the command title. The assert seems redundant as that will definitely fail if it's the wrong form since most forms don't have an "XML" submit button and if they don't then mechanize will throw an exception (and the comment will be there to explain to people what went wrong).
Given that in 5 years of open source we've only gotten to 50k bugs, I think it's going to be at least another year before we're to 6 digit bugs. :) We'll cross that bridge when we come to it. The commit-queue encountered the following flaky tests while processing attachment 75587 [details]: inspector/styles-disable-then-enable.html fast/workers/storage/use-same-database-in-page-and-workers.html Please file bugs against the tests. These tests were authored by dumi@chromium.org and pfeldman@chromium.org. The commit-queue is continuing to process your patch. Comment on attachment 75587 [details] Patch Rejecting patch 75587 from commit-queue. Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=eseidel-cq-sl', 'build', '--no-clean', '--no-update', '--build-style=both']" exit_code: 2 Last 500 characters of output: .compilers.gcc.4_2 CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/JavaScriptCallFrame.o /Projects/CommitQueue/WebCore/bindings/js/JavaScriptCallFrame.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/InspectorStyleSheet.o /Projects/CommitQueue/WebCore/inspector/InspectorStyleSheet.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 (13 failures) Full output: http://queues.webkit.org/results/6732133 Comment on attachment 75587 [details] Patch Clearing flags on attachment: 75587 Committed r73688: <http://trac.webkit.org/changeset/73688> All reviewed patches have been landed. Closing bug. Created attachment 76165 [details]
Fix spelling error
THE COMMIT QUEUE IS ALIVE! ITS STARTING TO MODIFY ITSELF! Committed r73950: <http://trac.webkit.org/changeset/73950> |