* SUMMARY The bugzilla-tool command is getting crowded. Move the mark-fixed subcommand to its own tool named mark-bug-fixed. * NOTES See Bug 28877 Comment #7 and Bug 28877 Comment #8.
We could move all of the commands into a separate commands.py, or just this command into a module which was then loaded an execute manually called by some wrapper script. I think I want to move away from having BugzillaTool hold all of the shared state, and instead have something on the Command baseclass. I want to basically kill the BugzillaTool class over time, and split the option parsing stuff off into its own class/file and the state off into some Command base class.
(In reply to comment #1) > We could move all of the commands into a separate commands.py, or just this > command into a module which was then loaded an execute manually called by some > wrapper script. > > I think I want to move away from having BugzillaTool hold all of the shared > state, and instead have something on the Command baseclass. I want to > basically kill the BugzillaTool class over time, and split the option parsing > stuff off into its own class/file and the state off into some Command base > class. So I completely misunderstood Bug 28877 Comment #7? Or is it okay to move this out?
You're welcome to do whatever you like. :) In general the idea behind doing all the Command subclasses was to share as much setup/teardown code as possible. But that shouldn't hold you back from writing other python scripts which use all of our new python modules. :)
*** Bug 29699 has been marked as a duplicate of this bug. ***
Created attachment 40035 [details] Patch v1
Committed r48700: <http://trac.webkit.org/changeset/48700>