sfink @ Mozilla One more Blog.mozilla.com weblog than you need

Scenario 1: you have a patch to some bug sitting in our mercurial queue. You want to attach it to a bug, but the bugzilla interface is painful and annoying. What do you do?

Use bzexport. It’s great! You can even request review at the same time.

What I really like about bzexport is that while writing and testing a patch, I’m in an editor and the command line. I may not even have a browser running, if I’m constantly re-starting it to test something out. Needing to go to the bugzilla web UI interrupts my flow. With bzexport, I can stay in the shell and move onto something else immediately.

Scenario 2: You have a patch, but haven’t filed a bug yet. Neither has anybody else. But your patch has a pretty good description of what the bug is. (This is common, especially for small things.) Do you really have to go through the obnoxious bug-filing procedure? It sure is tempting just to roll this fix up into some other vaguely related bug, isn’t it? Surely there’s a simple way to do things the right way without bouncing between interfaces?

Well, you’re screwed. Unless you’re willing to test something out for me. If not, please stop reading.

---

Great! You’re still here! Ok, give this modified version of bzexport a try. (Update: everything described in this post is now available in the official version of bzexport.)  It adds a --new option to the hg bzexport command that creates a new bug, then attaches your patch to it. My preferred way to use it, for a bug in the Javascript engine (product ‘Core’, component ‘JavaScript engine’):

hg bzexport --new -e -i -C javascript

That’ll grab off the top applied patch in your mercurial queue. The first line of its description (as set by hg qnew -e or hg qref -e) will be used for the bug title and the patch description; any other lines will be used for bug comments. It’ll create a bug, upload your patch as an attachment, and wash your car.

In case you only own a bicycle or your car is allergic to soap, here’s some detail on all those options I passed:

• --new: Create a new bug to attach your patch to. (Without this, it would use the existing bug given either on the command line or in the patch description.)
• -e(or –edit): Open up your text editor on a textual form where you can fill in all of the various values: bug title, product, component, comments, etc. If you omit this, it will prompt for anything it needs, but I prefer using this option to see everything at once.
• -i(or –interactive): That’s a lot of magic, and I know the idiot who wrote this code, so I want to be asked before it does anything irreversible. In this case, it’ll ask before creating the bug, and before uploading the attachment. I can cancel at any time.
• -C javascript (or –component javascript): This is for setting the product and component. You could say -C 'Core/JavaScript Engine' if you happen to have your product/component memorized. Or even --product Core --component 'JavaScript Engine' if you really like being explicit. But if you’re as lazy as I am, you can give a substring of just your component, and bzexport will scan through all components of all products and find substring matches. In this case, there is a unique match, and it’ll fill everything in for you. It Does The Right Thing if there are multiple matches — if you give the -e option, you’ll have a second chance to tell it the product and component, and if you still can’t be bothered (or you didn’t use the -e option in the first place), it will present a textual menu giving all of your options. For example, if I had said -C engine, it would give me a menu of the 4 products containing components with “engine” as a substring. If I foolishly chose ‘Mozilla Messaging’, it would set the product/component to ‘Mozilla Messaging/Release Engineering’, which is not at all what I wanted but might be if you are not me.

If you demand even more help in choosing a bugzilla product and component, install my mqext extension and run hg components (or perhaps hg components -f filename) to scan through the last 100k commits or so and look for the product/component of all bugs that touched the same files to provide a best guess as to the appropriate categorization.

So where do you come in? Why am I babbling on about this instead of just getting it reviewed by the maintainer (jdm), landing it, and shutting up?

Well, I did give jdm an earlier version, and he mostly liked it. But like I said, it’s a lot of magic (more than I went over above — there’s stuff for picking reviewers, possibly from the patch description, and setting a product version). It implements one particular workflow that I dreamt up. It makes sense to me, but I figure that other people probably have rather different ideas of how it should work and will be rather irritated by what I came up with. I’m not sure if all of this is 100% compatible with the previous bzexport workflow, so I’d like to be a little more confident that this is the right direction before updating what everybody’s using.

So please, especially if you’re an irritable person, give it a try and let me know what you think. It scratches my itch, but I’d like to try to scratch your itch too.

Figuratively, I mean.

Yuck.

How can I get that mental image out of my head? Argh!!

Anyway, one last thing — there’s also an hg newbug command in case you just want the bug-creation functionality, or want to do things in isolated steps. You still get all of the cookie-stealing goodness from bzexport (it’s awesome; it rifles around your Firefox default profile directory, tries to find the database containing your bugzilla cookie, does some funky magic to open it even if it’s locked down by sqlite’s WAL feature, and snatches away the cookie to use for your bugzilla operations. ted++.)

Tags: automation, hg, mozilla, mq, mqext, planet, tools

This entry was posted on Saturday, January 21st, 2012 at 10:36 pm and is filed under Uncategorized. You can follow any comments to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.