bzexport –new and hg newbug have landed
My bzexport changes adding a --new flag and an hg newbug command have landed. Ok, they landed months ago. See my previous blog post for details; all of the commands and options described there are still valid in the current version. But please pull from the official repo instead of my testing repo given in the earlier blog post.
Installing bzexport
mkdir -p ~/hg-extensions
cd ~/hg-extensions
hg clone http://hg.mozilla.org/users/tmielczarek_mozilla.com/bzexport
in the [extensions] section of your ~/.hgrc, add:
bzexport = ~/hg-extensions/bzexport/bzexport.py
Note to Windows users: unfortunately, I think the python packaged with MozillaBuild is missing the json.py package that bzexport needs. I think it still works if you use a system Python with json.py installed, but I’m not sure.
Trying it out
For the (understandably) nervous users out there, I’d like you to give it a try and I’ve made it safe to do so. Here are the levels of paranoia available:
Ultra-paranoid: landfill testing server
First, if you’re truly paranoid, you can add these lines to your ~/.hgrc file to make bugs go to the bugzilla testing instance:
[bzexport] # Testing api_server = https://api-dev.bugzilla.mozilla.org/test/1.0/ bugzilla = https://landfill.bugzilla.org/bzapi_sandbox/
Note that to avoid annoyance, you’ll want to go to that bugzilla URL in your default browser profile first and log in, so that bzexport can borrow your authentication cookies instead of prompting for the username and password that you’ve already forgotten. (And most of you will need to register over there first anyway.)
Honestly, though, you don’t need to worry this much. A number of people are already using bzexport successfully.
Moderately paranoid: -i (–interactive) flag
bzexport will do nothing to bugzilla without asking you when you use this flag. It’ll ask before creating a bug, it’ll ask before creating an attachment, and it’ll ask before obsoleting any attachments with matching filenames. I confess that it doesn’t fully describe the action it’s going to take, but at least it asks.
Note that if you say ‘y’ when it asks whether to create the bug, but ‘n’ when it asks whether to add the attachment, you will have a new bug with no attachment. I probably ought to hold off doing anything until it’s asked you everything, but right now it’s confirm-as-you-go.
Healthily paranoid: -e (–edit) flag
I almost always run with this flag. It pops up an editor with a form describing nearly everything relevant to what it’s going to do. You can tweak the bug title, the bug and attachment comments, the reviewers, and various other stuff. You can even fill in partial answers (eg you can just fill in the component but not the product, or a substring of a reviewer’s name) and it’ll give a series of text prompts after you exit the editor, to confirm anything that is still ambiguous. (If your reviewer matches multiple possibilities, it’ll give you a menu of matches. Similar for product and component.)
Note that you can use both -i and -e together, though that gets old fast.
Usage examples
You wrote a patch for a bug that has not yet been filed. It is sitting at the top of your mq queue.
hg qref -eto set the patch comment. (Not strictly necessary, but it’s better this way.)hg bzexport --new -e -C <component>
You wrote a patch for a bug that has already been filed. It is sitting at the top of your mq queue.
hg qref -eto set the patch comment. Include “Bug nnnn” somewhere in the first line.hg bzexport -e
You wrote a patch for a bug that has not yet been filed, you’ve already given it a reasonable comment, and it’s not at the top of your mq queue. It’s partway down, named my-cool-patch:
hg bzexport --new -e -C <component> my-cool-patch
You haven’t written a patch yet, but you want to create a new bug:
hg newbug -e -C <component>
You find it tiresome to use hg bzexport –new to create a new bug, then go back and use hg qref -e to add in the bug number. Couldn’t bzexport do that part too, since it’s creating the d&#n bug in the first place?
- add
update-patch=1to the[bzexport]section of your~/.hgrcfile
bzexport sucks. You want to file a bug on it.
hg newbug -e -C bzexport# This will go in product “Other Applications”, component “bzexport”
Forget about patches, you just want a way to programmatically create bugs.
hg newbug - C product/component --title "Bug title" --comment "Feature X is useless and you all suck"
You want to set severity, platform, CCs, version, or other fields on the bugs you create.
- Patches welcome
Advanced Usage
- I like to name all the patches in my mq queue after the bug that they apply to. In the unlikely event that you’d like to use the same naming convention, you can add rename-patch=1 to the [bzexport] section of your
~/.hgrc, and it’ll rename the patch for you when you create a new bug for it. (See known issues, though.) - Every time you request review, it’ll cache the mapping from whatever substring you used (eg “:bz”) to the full reviewer email address in
~/.bzexport. You can edit that file to add aliases that you’d like to use. (Useful when a substring like “bz” matches a bunch of people, but you know there’s only One True bz.) - Sometimes bzexport picks the wrong profile to use to find your authentication keys. There’s a
--ffprofileoption that you can use to tell it the right profile name to use. (I’ve had problems with Firefox changing which profile is my default profile, and looking for keys in the wrong place.) - hg newbug has a
--take-bugoption that will assign the bug to you.hg bzexport --newwill do this by default, but there’s--no-take-bugif you just want to attach a patch without assigning the bug to yourself.
Known Issues
- The rename-patch and update-patch configuration options only work when creating a bug with bzexport. If you are attaching a patch to an existing bug, the patch will not be renamed nor will it get a leading “Bug n – ” in its description.
- bzexport is slow. I blame it on BzAPI. (Or more properly, the API stuff that bzapi sits on top of.)
- I’m not watching the bzexport component in bugzilla. Oops. Just realized that. I’ll go do it now.
- ~/.bzexport caches reviewers even when you use full email addresses, so the file is a mess and editing it is a pain. Oopsie. Fortunately, I doubt anyone else ever will.
- Choosing which patch to obsolete works entirely by filename, which isn’t always right. For example, if you rename a patch in your queue, that will update the filename and when you use bzexport to update the patch, it won’t find the older version to obsolete. Also, you can’t obsolete multiple patches. bzexport should really have an option to prompt which attachments you’d like to obsolete.
- bugzilla requires the product version to be set when creating a bug. bzexport has no way of detecting the default version of a product. The
enter_bug.cgiform guesses based on the order of versions in the dropdown list, but BzAPI re-sorts the versions. I have a bug open on that, but for now, it guesses. You can override with--prodversionor by setting the field when you do -e.