Bug 28910 - Move bugzilla-tool mark-fixed to standalone mark-bug-fixed tool
Summary: Move bugzilla-tool mark-fixed to standalone mark-bug-fixed tool
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 29699 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-02 08:34 PDT by David Kilzer (:ddkilzer)
Modified: 2009-09-23 22:01 PDT (History)
2 users (show)

See Also:


Attachments
Patch v1 (13.77 KB, patch)
2009-09-23 19:27 PDT, David Kilzer (:ddkilzer)
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2009-09-02 08:34:27 PDT
* 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.
Comment 1 Eric Seidel (no email) 2009-09-02 13:55:25 PDT
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.
Comment 2 David Kilzer (:ddkilzer) 2009-09-02 19:20:14 PDT
(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?
Comment 3 Eric Seidel (no email) 2009-09-02 22:58:01 PDT
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. :)
Comment 4 David Kilzer (:ddkilzer) 2009-09-23 19:20:53 PDT
*** Bug 29699 has been marked as a duplicate of this bug. ***
Comment 5 David Kilzer (:ddkilzer) 2009-09-23 19:27:05 PDT
Created attachment 40035 [details]
Patch v1
Comment 6 David Kilzer (:ddkilzer) 2009-09-23 22:01:11 PDT
Committed r48700: <http://trac.webkit.org/changeset/48700>